Kategorie: Kubernetes

Memgraph Docker Extension: Empowering Real-Time Analytics with High Performance

Memgraph is an open source, in-memory graph database designed with real-time analytics in mind. Providing a high-performance solution, Memgraph caters to developers and data scientists who require immediate, actionable insights from complex, interconnected data.

What sets Memgraph apart is its high-speed data processing ability, delivering performance that makes it significantly faster than other graph databases. This, however, is not achieved at the expense of data integrity or reliability. Memgraph is committed to providing accurate and dependable insights as fast as you need them.

Built entirely on a C++ codebase, Memgraph leverages in-memory storage to handle complex real-time use cases effectively. Support for ACID transactions guarantees data consistency, while the Cypher query language offers a robust toolset for data structuring, manipulation, and exploration. 

Graph databases have a broad spectrum of applications. In domains as varied as cybersecurity, credit card fraud detection, energy management, and network optimization, Memgraph can efficiently analyze and traverse complex network structures and relationships within data. This analytical prowess facilitates real-time, in-depth revelations across a broad spectrum of industries and areas of study. 

In this article, we’ll show how using Memgraph as a Docker Extension offers a powerful and efficient way to leverage real-time analytics from a graph database. 

Architecture of Memgraph

The high-speed performance of Memgraph can be attributed to its unique architecture (Figure 1). Centered around graph models, the database represents data as nodes (entities) and edges (relationships), enabling efficient management of deeply interconnected data essential for a range of modern applications.

In terms of transactions, Memgraph upholds the highest standard. It uses the standardized Cypher query language over the Bolt protocol, facilitating efficient data structuring, manipulation, and exploration.

Figure 1: Components of Memgraph’s architecture.

The key components of Memgraph’s architecture are:

In-memory storage: Memgraph stores data in RAM for low-latency access, ensuring high-speed data retrieval and modifications. This is critical for applications that require real-time insights.

Transaction processing: Memgraph supports ACID (Atomicity, Consistency, Isolation, Durability) transactions, which means it guarantees that all database transactions are processed reliably and in a way that ensures data integrity, including when failures occur.

Query engine: Memgraph uses Cypher, a popular graph query language that’s declarative and expressive, allowing for complex data relationships to be easily retrieved and updated.

Storage engine: While Memgraph primarily operates in memory, it also provides a storage engine that takes care of data durability by persisting data on disk. This ensures that data won’t be lost even if the system crashes or restarts.

High availability and replication: Memgraph’s replication architecture can automatically replicate data across multiple machines, and it supports replication to provide high availability and fault tolerance.

Streaming and integration: Memgraph can connect with various data streams and integrate with different types of data sources, making it a versatile choice for applications that need to process and analyze real-time data.

To provide users with the utmost flexibility and control, Memgraph comprises several key components, each playing a distinct role in delivering seamless performance and user experience:

MemgraphDB — MemgraphDB is the heart of the Memgraph system. It deals with all concurrency problems, consistency issues, and scaling, both in terms of data and algorithm complexity. Using the Cypher query language, MemgraphDB allows users to query data and run algorithms. It also supports both push and pull operations, which means you can query data and run algorithms and get notified when something changes in the data.

Mgconsole — mgconsole is a command-line interface (CLI) used to interact with Memgraph from any terminal or operating system. 

Memgraph Lab — Memgraph Lab is a visual user interface for running queries and visualizing graph data. It provides a more interactive experience, enabling users to apply different graph styles, import predefined datasets, and run example queries. It makes data analysis and visualization more intuitive and user-friendly.

MAGE (Memgraph Advanced Graph Extensions) — MAGE is an open source library of graph algorithms and custom Cypher procedures. It enables high-performance processing of demanding graph algorithms on streaming data. With MAGE, users can run a variety of algorithms, from PageRank or community detection to advanced machine learning techniques using graph embeddings. Moreover, MAGE does not limit users to a specific programming language.

Based on those four components, Memgraph offers four different Docker images:

memgraph-platform — Installs MemgraphDB, mgconsole, Memgraph Lab, and MAGE

memgraph-mage — Installs MemgraphDB, mgconsole, and MAGE

memgraph — Installs MemgraphDB and mgconsole

MAGE × NVIDIA cuGraph — Installs everything that you need to run MAGE in combination with NVIDIA cuGraph

With more than 10K downloads from Docker Hub, Memgraph Platform is the most popular Memgraph Docker image, so the team decided to base the Memgraph Docker extension on it. Instructions are available in the documentation if you want to use any of the other images. Let’s look at how to install Memgraph Docker Extension.

Why run Memgraph as a Docker Extension?

Running Memgraph as a Docker Extension offers a streamlined experience to users who are already familiar with Docker Desktop, simplifying the deployment and management of the graph database. Docker provides an ideal environment to bundle, ship, and run Memgraph in a lightweight, isolated setup. This encapsulation not only promotes consistent performance across different systems but also simplifies the setup process.

Moreover, Docker Desktop is the only prerequisite to run Memgraph as an extension. This means that once you have Docker installed, you can easily set up and start using Memgraph, eliminating the need for additional software installations or complex configuration steps.

Getting started

Working with Memgraph as a Docker Extension begins with opening the Docker Desktop (Figure 2). Here are the steps to follow:

Choose Extensions in the left sidebar.

Switch to the Browse tab.

In the Filters drop-down, select the Database category.

Find Memgraph and then select Install. 

Figure 2: Installing Memgraph Docker Extension.

That’s it! Once the installation is finished, select Connect now (Figure 3).

Figure 3: Connecting to Memgraph database using Memgraph Lab.

What you see now is Memgraph Lab, a visual user interface designed for running queries and visualizing graph data. With a range of pre-prepared datasets, Memgraph Lab provides an ideal starting point for exploring Memgraph, gaining proficiency in Cypher querying, and effectively visualizing query results.  

Importing the Pandora Papers datasets

For the purposes of this article, we will import the Pandora Papers dataset. To import the dataset, choose Datasets in the Memgraph Lab sidebar and then Load Dataset (Figure 4).

Figure 4: Importing the Pandora Papers dataset.

Once the dataset is loaded, select Explore Query Collection to access a selection of predefined queries (Figure 5).

Figure 5: Exploring the Pandora Papers dataset query collection.

Choose one of the queries and select Run Query (Figure 6).

Figure 6: Running the Cypher query.

And voilà! Welcome to the world of graphs. You now have the results of your query (Figure 7). Now that you’ve run your first query, feel free to explore other queries in the Query Collection, import a new dataset, or start adding your own data to the database.

Figure 7: Displaying the query result as a graph.

Conclusion

Memgraph, as a Docker Extension, offers an accessible, powerful, and efficient solution for anyone seeking to leverage real-time analytics from a graph database. Its unique architecture, coupled with a streamlined user interface and a high-speed query engine, allows developers and data scientists to extract immediate, actionable insights from complex, interconnected data.

Moreover, with the integration of Docker, the setup and use of Memgraph become remarkably straightforward, further expanding its appeal to both experienced and novice users alike. The best part is the variety of predefined datasets and queries provided by the Memgraph team, which serve as excellent starting points for users new to the platform.

Whether you’re diving into the world of graph databases for the first time or are an experienced data professional, Memgraph’s Docker Extension offers an intuitive and efficient solution. So, go ahead and install it on Docker Desktop and start exploring the intriguing world of graph databases today. If you have any questions about Memgraph, feel free to join Memgraph’s vibrant community on Discord.

Learn more

Install Memgraph’s Docker Extension.

Get the latest release of Docker Desktop.

Vote on what’s next! Check out our public roadmap.

Have questions? The Docker community is here to help.

New to Docker? Get started.

Quelle: https://blog.docker.com/feed/

Protecting Secrets with Docker

Modern software is interconnected. When you develop an application, it has to communicate with other services — on your infrastructure, cloud infrastructure services, or third-party applications. Of course, you don’t want just anyone to masquerade as you, so you use secrets like SSH keys or API tokens to make the communication secure. But having these secrets means you have to keep them secret.

Unfortunately, sometimes the secrets escape. When this happens, it can allow bad actors to maliciously use the secrets or post them on the “dark web” for others to use. They can insert vulnerabilities into your code. They can impersonate you or deny legitimate users access to resources. And, if the secret is for something billable (like public cloud infrastructure), they can cost you a lot of money. No matter what other costs you face, the public relations impact can cause your users to lose trust in you.

In this article, we’ll cover a few ways that Docker can help keep secrets from leaking.

Before you read on: If your secrets have been exposed, the first step is to immediately invalidate them and check for compromises.

Controlling access with Docker Hub

The principle of least privilege is a powerful part of your security posture. If someone doesn’t need access to your Docker Hub images, they shouldn’t have access. Docker Hub provides private repositories so that you can keep your images to yourself. Docker Personal subscribers can create one private repository, while Docker Pro, Docker Team, and Docker Business subscriptions offer unlimited private repositories.

Keep in mind that even with private repositories, Docker Hub is not for storing account secrets. Private repositories are a layer in your defense-in-depth model.

Of course, sometimes you want to selectively share your images. Docker Pro, Docker Team, and Docker Business subscribers can add collaborators — accounts that can push or pull images in a private repository. Docker Pro subscribers can add one collaborator to a repository. Docker Teams and Docker Business subscribers can add up to the organization size. This means you can share images with the people who need them — and no one else.

Keeping secrets out

What’s better than protecting the secrets on your Docker image? Not having them in the image in the first place! While there are cases where you need to store a secret in order to make the proper connections, many cases of secret leakage involve secrets that were added accidentally.

The best way to avoid accidentally adding secrets is to use a secret manager, such as AWS Secrets Manager, HashiCorp Vault, or 1Password, which has some CLI options. If you have to keep the secrets in a local environment, you can prevent files from accidentally winding up on your image by adding them to the .dockerignore file. For example, if you’re worried about accidentally adding SSH keys to your image, you can include: *id_rsa*

This approach works well for secrets in files with predictable names. If you’re always storing your cloud credentials in a file called cloud_key.txt, then you’re well-covered. But you won’t catch cloud_credentials.txt.

You can add another layer of security with secret scanners. Tools like Aqua Security Trivy, Anchore, and JFrog Xray search your files for things that look like secrets. If you run the scanner before pushing your image, then you can catch the secret before it escapes. Many secrets scanners can be tied into a Git commit hook as well to prevent secrets from being included in your code.

Conclusion

Keeping your secrets secret is an ongoing process but worth the effort. Like everything in cybersecurity, there’s no one magic solution, but Docker provides features that you can use to help prevent leaking secrets.

To get the most from private repositories and collaborators, check out our subscription offerings. We’re considering adding secret scanning to Docker Scout. If you’d like to see this capability, upvote the issue on our public roadmap.

Learn more

Get the latest release of Docker Desktop.

 Vote on what’s next! Check out our public roadmap.

 Have questions? The Docker community is here to help.

 New to Docker? Get started.

Quelle: https://blog.docker.com/feed/

Improve Docker Compose Modularity with “include”

This blog post discusses a feature available now in Compose v2.20.0 and in our upcoming Docker Desktop 4.22 release.

The docker command line supports many flags to fine-tune your container, and it’s difficult to remember them all when replicating an environment. Doing so is even harder when your application is not a single container but a combination of many containers with various dependency relationships. Based on this, Docker Compose quickly became a popular tool because it lets users declare all the infrastructure details for a container-based application into a single YAML file using a simple syntax directly inspired by the docker run… command line.

Still, an issue persists for large applications using dozens, maybe hundreds, of containers, with ownership distributed across multiple teams. When using a monorepo, teams often have their own “local” Docker Compose file to run a subset of the application, but then they need to rely on other teams to provide a reference Compose file that defines the expected way to run their own subset.

This issue is not new and was debated in 2014 when Docker Compose was a fresh new project and issue numbers had only three digits. Now we’ve introduced the ability to “compose compose files” to address this need — even before this issue reaches its 10th anniversary!

In this article, we’ll show how the new include attribute, introduced in Docker Compose 2.20, makes Compose files more modular and reusable.

Extend a Compose file

Docker Compose lets you reuse an existing Compose file using the extends mechanism. This special configuration attribute lets you refer to another Compose file and select a service you want to also use in your own application, with the ability to override attributes for your own needs.

services:
database:
extends:
file: ../commons/compose.yaml
service: db

That’s a good solution as long as you only need a single service to be shared, and you know about its internal details so you know how to tweak configuration. But, it is not an acceptable solution when you want to reuse someone else’s configuration as a “black box” and don’t know about its own dependencies.

Merge Compose files

Another option is to merge a set of Compose files together. Docker Compose accepts a set of files and will merge and override the service definition to eventually create a composite Compose application model.

This approach has been utilized for years, but it comes with a specific challenge. Namely, Docker Compose supports relative paths for the many resources to be included in the application model, such as: build context for service images, location of file defining environment variables, path to a local directory used in a bind-mounted volume.

With such a constraint, code organization in a monorepo can become difficult, as a natural choice would be to have dedicated folders per team or component, but then the Compose files relative paths won’t be relevant.

Let’s play the role of the “database” team and define a Compose file for the service we are responsible for. Next, we build our own image from a Dockerfile and have a reference environment set as an env file:

services:
database:
builld: .
env-file:
– ./db.env

Now, let’s switch to another team and build a web application, which requires access to the database:

services:
webapp:
depends_on:
– database

Sounds good, until we try to combine those, running the following from the webapp directory: docker compose -f compose.yaml -f ../database/compose.yaml.

In doing so, the relative paths set by the second Compose file won’t get resolved as designed by the authors but from the local working directory. Thus, the resulting application won’t work as expected.

Reuse content from other teams

The include flag was introduced for this exact need. As the name suggests, this new top-level attribute will get a whole Compose file included in your own application model, just like you did a full copy/paste. The only difference is that it will manage relative path references so that the included Compose file will be parsed the way the author expects, running from its original location. This capability makes it way easier for you to reuse content from another team, without needing to know the exact details.

include:
../database/compose.yaml

services:
webapp:
depends_on:
– database

In this example, an infrastructure team has prepared a Compose file to manage a database service, maybe including some replicas, web UI to inspect data, isolated networks, volumes for data persistence, etc.

An application relying on this service doesn’t need to know about those infrastructure details and will consume the Compose file as a building block it can rely on. Thus, the infrastructure team can refactor its own database component to introduce additional services without the dependent teams being impacted.

This approach also comes with the bonus that the dependency on another Compose file is now explicit, and users don’t need to include additional flags on each Compose command they run. They can instead rely on the beloved docker compose up command without any additional knowledge of the application architecture.

Conclusion

With microservices and monorepo, it becomes common for an application to be split into dozens of services, and complexity is moved from code into infrastructure and configuration file. Docker Compose fits well with simple applications but is harder to use in such a context. At least it was, until now.

With include support, Docker Compose makes it easier to modularize such complex applications into sub-compose files. This capability allows application configuration to be simpler and more explicit. It also helps to reflect the engineering team responsible for the code in the config file organization. With each team able to reflect in configuration the way it depends on other’s work, there’s a natural approach to compose.yaml files organization.

Read more about this new include feature on the dedicated Compose specification page and experiment with it by upgrading Docker Compose to v2.20 or later.

Learn more

Read the include documentation

Get the latest release of Docker Desktop.

Vote on what’s next! Check out our public roadmap.

Have questions? The Docker community is here to help

New to Docker? Get started.

Quelle: https://blog.docker.com/feed/

Build and Deploy a LangChain-Powered Chat App with Docker and Streamlit

We are happy to have another great AI/ML story to share from our community. In this blog post, MA Raza, Ph.D., provides a guide to building and deploying a LangChain-powered chat app with Docker and Streamlit.

This article reinforces the value that Docker brings to AI/ML projects — the speed and consistency of deployment, the ability to build once and run anywhere, and the time-saving tools available in Docker Desktop that accelerate the overall development workflow.

In this article, we will explore the process of creating a chat app using LangChain, OpenAI API, and Streamlit frameworks. We will demonstrate the use of Docker and Docker Compose for easy deployment of the app on either in-house or cloud servers.

We have created and deployed a demo app (Figure 1) on Streamlit Public Cloud and Google App Engine for a quick preview.

Figure 1: Screenshot of the chat app: LangChain demo.

We’ve developed a GitHub project (Figure 2) that includes comprehensive instructions and the demo chat app that runs on LangChain. We’ve also configured the Poetry framework for the Python Environment Manager.

Figure 2: Information on the project on GitHub.

Chat app components and technologies

We’ll briefly describe the app components and frameworks utilized to create the template app.

LangChain Python framework

The LangChain framework enables developers to create applications using powerful large language models (LLMs). Our demo chat app is built on a Python-based framework, with the OpenAI model as the default option. However, users have the flexibility to choose any LLM they prefer.

The LongChain framework effortlessly manages input prompts and establishes connections between responses generated from LLMs APIs.

OpenAI model

For demonstration purposes, we are using OpenAI API to generate responses upon submission of prompts.

Frontend Streamlit UI

Streamlit is a lightweight and faster way of building and sharing data apps. A simple UI with a Streamlit framework is developed to interact with the chat app.

Deployment with Docker

Docker is useful in developing and deploying apps to any server without worrying about dependencies and environments. After the demo app is developed and running fine locally, we have added Docker support.

FROM python:3.10-slim-bullseye

ENV HOST=0.0.0.0

ENV LISTEN_PORT 8080

EXPOSE 8080

RUN apt-get update && apt-get install -y git

COPY ./requirements.txt /app/requirements.txt

RUN pip install –no-cache-dir –upgrade -r /app/requirements.txt

WORKDIR app/

COPY ./demo_app /app/demo_app
COPY ./.streamlit /app/.streamlit

CMD ["streamlit", "run", "demo_app/main.py", "–server.port", "8080"]

The previous code shows the contents of the Dockerfile used to generate the Docker image of the demo app. To build the image, we use:

docker build -t langchain-chat-app .

Docker optimization for light and fast builds

When deploying apps for enterprise applications, we have to be mindful of the resources being utilized and the execution/deploying life cycle computations.

We have also addressed the concerns on how to optimize the Docker build process to solve the problem of image size and build it fast for every iteration of source change etc. Refer to the “Blazing fast Python Docker builds with Poetry” article for details on various tricks for optimizing Docker.

# The builder image, used to build the virtual environment
FROM python:3.11-buster as builder

RUN apt-get update && apt-get install -y git

RUN pip install poetry==1.4.2

ENV POETRY_NO_INTERACTION=1
POETRY_VIRTUALENVS_IN_PROJECT=1
POETRY_VIRTUALENVS_CREATE=1
POETRY_CACHE_DIR=/tmp/poetry_cache

ENV HOST=0.0.0.0
ENV LISTEN_PORT 8080
EXPOSE 8080

WORKDIR /app

#COPY pyproject.toml ./app/pyproject.toml
#COPY poetry.lock ./app/poetry.lock
COPY pyproject.toml poetry.lock ./

RUN poetry install –without dev –no-root && rm -rf $POETRY_CACHE_DIR

# The runtime image, used to just run the code provided its virtual environment
FROM python:3.11-slim-buster as runtime

ENV VIRTUAL_ENV=/app/.venv
PATH="/app/.venv/bin:$PATH"

COPY –from=builder ${VIRTUAL_ENV} ${VIRTUAL_ENV}

COPY ./demo_app ./demo_app
COPY ./.streamlit ./.streamlit

CMD ["streamlit", "run", "demo_app/main.py", "–server.port", "8080"]

In this Dockerfile, we have two runtime image tags. In the first one, we create a Poetry environment to form a virtual environment. Although the app is run in the second runtime image, the application is run after activating the virtual environment created in the first step.

Next, we’ll build a Docker image using DOCKER_BUILDKIT, which offers modern tooling to create Docker Images quickly and securely.

DOCKER_BUILDKIT=1 docker build –target=runtime . -t langchain-chat-app:latest

Docker-compose.yaml file

To run the app, we have also included the docker-compose.yml with the following contents:

version: ‘3’
services:
langchain-chat-app:
image: langchain-chat-app:latest
build: ./app
command: streamlit run demo_app/main.py –server.port 8080
volumes:
– ./demo_app/:/app/demo_app
ports:
– 8080:8080

To run the app on a local server, use the following command:

docker-compose up

Infrastructures

With support for Docker, the app can be deployed to any cloud infrastructure by following basic guides. We deployed the app on the following infrastructures.

Streamlit Public Cloud

Deploying Streamlit App on its public cloud is pretty straightforward with a GitHub account and repository. A deployed app can be accessed the LangChain demo.

Google App Engine

We have tried deploying the app on Google App Engine using Docker. The repo includes an app.yaml configuration file to deploy the following contents:

# With Dockerfile
runtime: custom
env: flex
# This sample incurs costs to run on the App Engine flexible environment.
# The settings below are to reduce costs during testing and are not appropriate
# for production use. For more information, see:
# https://cloud.google.com/appengine/docs/flexible/python/configuring-your-app-with-app-yaml

manual_scaling:
instances: 1
resources:
cpu: 1
memory_gb: 0.5
disk_size_gb: 10

To deploy the chat app on Google App Engine, we used the following commands after installing the gcloud Python SDK:

gcloud app create –project=[YOUR_PROJECT_ID]
gcloud config set project [YOUR_PROJECT_ID]
gcloud app deploy app.yaml

A sample app deployed on Google App Engine (Figure 3) can be accessed through:

Figure 3: Link to a sample app deployed on Google App Engine.

Deploying the app using Google Cloud Run

We can also deploy the app on Google Cloud using the Cloud Run Service of GCP. Deploying an app using Cloud Run is faster than Google App Engine.

Here are the relevant features of adopting this method:

Package the application in a container.

Push the container to the artifacts registry.

Deploy the service from the pushed container.

Let’s go through the steps being followed to deploy the app using Google Cloud Run. We assume a project is created on Google Cloud already.

1. Enable the service:You can enable the services using gcloud sdk:

gcloud services enable cloudbuild.googleapis.com
gcloud services enable run.googleapis.com

2. Create and add roles to service account:With the following set of commands, we create a service account and set appropriate permissions. Modify the service SERVICE_ACCOUNT and PROJECT_ID:

gcloud iam service-accounts create langchain-app-cr
–display-name="langchain-app-cr"

gcloud projects add-iam-policy-binding langchain-chat
–member="serviceAccount:langchain-app-cr@langchain-chat.iam.gserviceaccount.com"
–role="roles/run.invoker"

gcloud projects add-iam-policy-binding langchain-chat
–member="serviceAccount:langchain-app-cr@langchain-chat.iam.gserviceaccount.com"
–role="roles/serviceusage.serviceUsageConsumer"

gcloud projects add-iam-policy-binding langchain-chat
–member="serviceAccount:langchain-app-cr@langchain-chat.iam.gserviceaccount.com"
–role="roles/run.admin"

3. Generate and push the Docker image:Using the following commands, we can generate and push the image to the Artifacts Registry. However, if this is the first time, we need to create the repository with permissions for the Docker placeholder:

DOCKER_BUILDKIT=1 docker build –target=runtime . -t australia-southeast1-docker.pkg.dev/langchain-chat/app/langchain-chat-app:latest
docker push australia-southeast1-docker.pkg.dev/langchain-chat/app/langchain-chat-app:latest

Here are the required commands to generate the Artifacts Repository and assign permissions:

gcloud auth configure-docker australia-southeast1-docker.pkg.dev

gcloud artifacts repositories create app
–repository-format=docker
–location=australia-southeast1
–description="A Langachain Streamlit App"
–async

The app will now be deployed.

Conclusion

This article delves into the various tools and technologies required for developing and deploying a chat app that is powered by LangChain, OpenAI API, and Streamlit. The Docker framework is also utilized in the process.

The application demonstration is available on both Streamlit Public Cloud and Google App Engine. Thanks to Docker support, developers can deploy it on any cloud platform they prefer.

This project can serve as a foundational template for rapidly developing apps that utilize the capabilities of LLMs. You can find more of Raza’s projects on his GitHub page.

Do you have an interesting use case or story about Docker in your AI/ML workflow? We would love to hear from you and maybe even share your story.

This post was originally published on Level Up Coding and is reprinted with permission.

Learn more

Get the latest release of Docker Desktop.

Vote on what’s next! Check out our public roadmap.

Have questions? The Docker community is here to help.

New to Docker? Get started.

Quelle: https://blog.docker.com/feed/

Supercharging AI/ML Development with JupyterLab and Docker

JupyterLab is an open source application built around the concept of a computational notebook document. It enables sharing and executing code, data processing, visualization, and offers a range of interactive features for creating graphs. 

The latest version, JupyterLab 4.0, was released in early June. Compared to its predecessors, this version features a faster Web UI, improved editor performance, a new Extension Manager, and real-time collaboration.

If you have already installed the standalone 3.x version, evaluating the new features will require rewriting your current environment, which can be labor-intensive and risky. However, in environments where Docker operates, such as Docker Desktop, you can start an isolated JupyterLab 4.0 in a container without affecting your installed JupyterLab environment. Of course, you can run these without impacting the existing environment and access them on a different port. 

In this article, we show how to quickly evaluate the new features of JupyterLab 4.0 using Jupyter Docker Stacks on Docker Desktop, without affecting the host PC side.

Why containerize JupyterLab?

Users have downloaded the base image of JupyterLab Notebook stack Docker Official Image more than 10 million times from Docker Hub. What’s driving this significant download rate? There’s an ever-increasing demand for Docker containers to streamline development workflows, while allowing JupyterLab developers to innovate with their choice of project-tailored tools, application stacks, and deployment environments. Our JupyterLab notebook stack official image also supports both AMD64 and Arm64/v8 platforms.

Containerizing the JupyterLab environment offers numerous benefits, including the following:

Containerization ensures that your JupyterLab environment remains consistent across different deployments. Whether you’re running JupyterLab on your local machine, in a development environment, or in a production cluster, using the same container image guarantees a consistent setup. This approach helps eliminate compatibility issues and ensures that your notebooks behave the same way across different environments.

Packaging JupyterLab in a container allows you to easily share your notebook environment with others, regardless of their operating system or setup. This eliminates the need for manually installing dependencies and configuring the environment, making it easier to collaborate and share reproducible research or workflows. And this is particularly helpful in AI/ML projects, where reproducibility is crucial.

Containers enable scalability, allowing you to scale your JupyterLab environment based on the workload requirements. You can easily spin up multiple containers running JupyterLab instances, distribute the workload, and take advantage of container orchestration platforms like Kubernetes for efficient resource management. This becomes increasingly important in AI/ML development, where resource-intensive tasks are common.

Getting started

To use JupyterLab on your computer, one option is to use the JupyterLab Desktop application. It’s based on Electron, so it operates with a GUI on Windows, macOS, and Linux. Indeed, using JupyterLab Desktop makes the installation process fairly simple. In a Windows environment, however, you’ll also need to set up the Python language separately, and, to extend the capabilities, you’ll need to use pip to set up packages.

Although such a desktop solution may be simpler than building from scratch, we think the combination of Docker Desktop and Docker Stacks is still the more straightforward option. With JupyterLab Desktop, you cannot mix multiple versions or easily delete them after evaluation. Above all, it does not provide a consistent user experience across Windows, macOS, and Linux.

On a Windows command prompt, execute the following command to launch a basic notebook: 

docker container run -it –rm -p 10000:8888 jupyter/base-notebook

This command utilizes the jupyter/base-notebook Docker image, maps the host’s port 10000 to the container’s port 8888, and enables command input and a pseudo-terminal. Additionally, an option is added to delete the container once the process is completed.

After waiting for the Docker image to download, access and token information will be displayed on the command prompt as follows. Here, rewrite the URL http://127.0.0.1:8888 to http://127.0.0.1:10000 and then append the token to the end of this URL. In this example, the output will look like this:

Displayed on screen: http://127.0.0.1:8888/lab?token=6e302b2c99d56f1562e082091f4a3236051fb0a4135e10bb

To be entered in the browser address: http://127.0.0.1:10000/lab?token=6e302b2c99d56f1562e082091f4a3236051fb0a4135e10bb

Note that this token is specific to my environment, so copying it will not work for you. You should replace it with the one actually displayed on your command prompt.

Then, after waiting for a short while, JupyterLab will launch (Figure 1). From here, you can start a Notebook, access Python’s console environment, or utilize other work environments.

Figure 1. The page after entering the JupyterLab token. The left side is a file list, and the right side allows you to open Notebook creation, Python console, etc.

The port 10000 on the host side is mapped to port 8888 inside the container, as shown in Figure 2.

Figure 2. The host port 10000 is mapped to port 8888 inside the container.

In the Password or token input form on the screen, enter the token displayed in the command line or in the container logs (the string following token=), and select Log in, as shown in Figure 3.

Figure 3. Enter the token that appears in the container logs.

By the way, in this environment, the data will be erased when the container is stopped. If you want to reuse your data even after stopping the container, create a volume by adding the -v option when launching the Docker container.

To stop this container environment, click CTRL-C on the command prompt, then respond to the Jupyter server’s prompt Shutdown this Jupyter server (y/[n])? with y and press enter. If you are using Docker Desktop, stop the target container from the Containers.

Shutdown this Jupyter server (y/[n])? y
[C 2023-06-26 01:39:52.997 ServerApp] Shutdown confirmed
[I 2023-06-26 01:39:52.998 ServerApp] Shutting down 5 extensions
[I 2023-06-26 01:39:52.998 ServerApp] Shutting down 1 kernel
[I 2023-06-26 01:39:52.998 ServerApp] Kernel shutdown: 653f7c27-03ff-4604-a06c-2cb4630c098d

Once the display changes as follows, the container is terminated and the data is deleted.

When the container is running, data is saved in the /home/jovyan/work/ directory inside the container. You can either bind mount this as a volume or allocate it as a volume when starting the container. By doing so, even if you stop the container, you can use the same data again when you restart the container:

docker container run -it -p 10000:8888
-v “%cd%”:/home/jovyan/work
jupyter/base-notebook

Note: The symbol signifies that the command line continues on the command prompt. You may also write the command in a single line without using the symbol. However, in the case of Windows command prompt, you need to use the ^ symbol instead.

With this setup, when launched, the JupyterLab container mounts the /work/ directory to the folder where the docker container run command was executed. Because the data persists even when the container is stopped, you can continue using your Notebook data as it is when you start the container again.

Plotting using the famous Iris flower dataset

In the following example, we’ll use the Iris flower dataset, which consists of 150 records in total, with 50 samples from each of three types of Iris flowers (Iris setosa, Iris virginica, Iris versicolor). Each record consists of four numerical attributes (sepal length, sepal width, petal length, petal width) and one categorical attribute (type of iris). This data is included in the Python library scikit-learn, and we will use matplotlib to plot this data.

When trying to input the sample code from the scikit-learn page (the code is at the bottom of the page, and you can copy and paste it) into iPython, the following error occurs (Figure 4).

Figure 4. Error message occurred due to missing “matplotlib” module.

This is an error message on iPython stating that the “matplotlib” module does not exist. Additionally, the “scikit-learn” module is needed.

To avoid these errors and enable plotting, run the following command. Here, !pip signifies running the pip command within the iPython environment:

!pip install matplotlib scikit-learn

By pasting and executing the earlier sample code in the next cell on iPython, you can plot and display the Iris dataset as shown in Figure 5.

Figure 5. When the sample code runs successfully, two images will be output.

Note that it can be cumbersome to use the !pip command to add modules every time. Fortunately, you can add also add modules in the following ways:

By creating a dedicated Dockerfile

By using an existing group of images called Jupyter Docker Stacks

Building a Docker image

If you’re familiar with Dockerfile and building images, this five-step method is easy. Also, this approach can help keep the Docker image size in check. 

Step 1. Creating a directory

To build a Docker image, the first step is to create and navigate to the directory where you’ll place your Dockerfile and context:

mkdir myjupyter && cd myjupyter

Step 2. Creating a requirements.txt file

Create a requirements.txt file and list the Python modules you want to add with the pip command:

matplotlib
scikit-learn

Step 3. Writing a Dockerfile

FROM jupyter/base-notebook
COPY ./requirements.txt /home/jovyan/work
RUN python -m pip install –no-cache -r requirements.txt

This Dockerfile specifies a base image jupyter/base-notebook, copies the requirements.txt file from the local directory to the /home/jovyan/work directory inside the container, and then runs a pip install command to install the Python packages listed in the requirements.txt file.

Step 4. Building the Docker image

docker image build -t myjupyter

Step 5. Launching the container

docker container run -it -p 10000:8888
-v “%cd%”:/home/jovyan/work
myjupyter

Here’s what each part of this command does:

The docker run command instructs Docker to run a container.

The -it  option attaches an interactive terminal to the container.

The -p 10000:8888 maps port 10000 on the host machine to port 8888 inside the container. This allows you to access Jupyter Notebook running in the container via http://localhost:10000 in your web browser.

The -v “%cd%”:/home/jovyan/work mounts the current directory (%cd%) on the host machine to the /home/jovyan/work directory inside the container. This enables sharing files between the host and the Jupyter Notebook.

In this example, myjupyter is the name of the Docker image you want to run. Make sure you have the appropriate image available on your system. The operation after startup is the same as before. You don’t need to add libraries with the !pip command because the necessary libraries are included from the start.

How to use Jupyter Docker Stacks’ images

To execute the JupyterLab environment, we will utilize a Docker image called jupyter/scipy-notebook from the Jupyter Docker Stacks. Please note that the running Notebook will be terminated. After entering Ctrl-C on the command prompt, enter y and specify the running container.

Then, enter the following to run a new container:

docker container run -it -p 10000:8888
-v “%cd%”:/home/jovyan/work
jupyter/scipy-notebook

​​This command will run a container using the jupyter/scipy-notebook image, which provides a Jupyter Notebook environment with additional scientific libraries. 

Here’s a breakdown of the command:

The docker run command starts a new container.

The -it option attaches an interactive terminal to the container.

The -p 10000:8888 maps port 10000 on the host machine to port 8888 inside the container, allowing access to Jupyter Notebook at http://localhost:10000.

The -v “$(pwd)”:/home/jovyan/work mounts the current directory ($(pwd)) on the host machine to the /home/jovyan/work directory inside the container. This enables sharing files between the host and the Jupyter Notebook.

The jupyter/scipy-notebook is the name of the Docker image used for the container. Make sure you have this image available on your system.

The previous JupyterLab image was a minimal Notebook environment. The image we are using this time includes many packages used in the scientific field, such as numpy and pandas, so it may take some time to download the Docker image. This one is close to 4GB in image size.

Once the container is running, you should be able to run the Iris dataset sample immediately without having to execute pip like before. Give it a try.

Some images include TensorFlow’s deep learning library, ones for the R language, Julia programming language, and Apache Spark. See the image list page for details.

In a Windows environment, you can easily run and evaluate the new version of JupyterLab 4.0 using Docker Desktop. Doing so will not affect or conflict with the existing Python language environment. Furthermore, this setup provides a consistent user experience across other platforms, such as macOS and Linux, making it the ideal solution for those who want to try it.

Conclusion

By containerizing JupyterLab with Docker, AI/ML developers gain numerous advantages, including consistency, easy sharing and collaboration, and scalability. It enables efficient management of AI/ML development workflows, making it easier to experiment, collaborate, and reproduce results across different environments. With JupyterLab 4.0 and Docker, the possibilities for supercharging your AI/ML development are limitless. So why wait? Embrace containerization and experience the true power of JupyterLab in your AI/ML projects.

References

JupyterLab documentation

Docker Stacks documentation 

Learn more

Get the latest release of Docker Desktop.

Vote on what’s next! Check out our public roadmap.

Have questions? The Docker community is here to help.

New to Docker? Get started.

Quelle: https://blog.docker.com/feed/

4 Reasons I’m Excited to Attend DockerCon 2023

DockerCon is back! DockerCon is back! DockerCon is back! I can’t tell you how excited this makes me. Now, you may recognize that I work at Docker, but I haven’t always. Although I’ve worked at Docker for about 18 months, I’ve been in the Docker space for a long time. In fact, my first presentation about Docker was all the way back in December 2015.

Since then, I’ve helped organize, run, and speak at many meetups, and I was recognized as a Docker Captain in March 2017. I even received the inaugural Community Leader of the Year award for the North America region in 2018. As I look back throughout my career, many of my fondest memories can be attributed to my time at DockerCon. This will be my sixth in-person DockerCon, and here are four reasons I’m happy to be back in person this year.

Let’s go!

Michael Irwin at DockerCon EU 2018 in Barcelona.

#1 — Developer-focused content

We’ve all been to many “developer-focused” conferences, only to find out most of the sessions are sponsored sessions, the keynotes are relatively boring, and there really isn’t much focus on developers. I remember going to DockerCons and learning everything about Docker’s latest features, scaling our efforts to my team and across the organization, deepening my understanding of various cloud-native design patterns and architectures, and helping my team be as productive as possible. Especially earlier in my career, this experience helped me become the developer I am today.

As I’m helping plan DockerCon this year, I’ll admit we want all of the same things from the past, just updated. We want to help each and every developer better their craft and better deliver results for their customers… whoever they might be.

A selfie before my “Containers for Beginners” talk at DockerCon 2019 in San Francisco.

#2 — The hallway track

Honestly, this is probably one of my favorite parts of DockerCon.The Hallway Track is a special track of DockerCon in which attendees can network and learn from each other. If you want to learn about something, simply make a request! If you want to teach others, submit a session! Then, small groups get together and just chat. These hallway moments have truly been some of the best moments of DockerCon, both learning and teaching. There’s simply no better way to learn than from others who have walked the same journey.

The hallway track offers many chances to learn and connect.

#3 — Reconnecting with and making new friends

During my time as a Docker Captain from 2017-2022 (I had to semi-retire when I joined Docker), DockerCon was such a fun time to get together and spend time with my fellow Captains. In many ways, this felt like a family reunion. We learned together, taught each other, and provided insight and direction to the Docker product and executive teams. 

Although connecting with old friends was great, I always made new friends every year. Many of those came from the Hallway Track, but random conversations at meals, the conference party, and other one-offs have provided me with friendships and contacts I still use to this day. Whenever I’m stuck with any problem, there’s a good chance I can reach out to someone that I met at DockerCon.

Docker Captains gathered at DockerCon EU 2017 in Copenhagen.

Group selfie taken during a pre-conference bike ride at DockerCon 2019 in San Francisco.

#4 — Fun all around!

I may or may not be known for roaming around the DockerCon EU 2017 vendor hall in an inflatable dinosaur suit or using that same suit to start my “Containers for Beginners” talk at DockerCon 2019. Why? To be completely honest, because it’s fun! And while a conference isn’t only about having fun, it’s certainly a lot easier to be a part of a community when you’re doing so. DockerCon is not afraid to have a little bit of fun.

Me wearing a dino suit at the Docker booth at DockerCon EU 2017 in Copenhagen.

While these are some of the reasons I’m excited to have DockerCon back in person this year, and I’m sure there are tons more! We’d love to hear what makes you excited. Tweet #DockerCon why you’re excited, and we just might highlight you.

Learn more at the DockerCon 2023 website and register by August 31 to take advantage of early bird pricing. 

Learn more

Register for DockerCon 2023.

Get the latest release of Docker Desktop.

Vote on what’s next! Check out our public roadmap.

Have questions? The Docker community is here to help.

New to Docker? Get started.

Quelle: https://blog.docker.com/feed/

Why Are There More Than 100 Million Pull Requests for AI/ML Images on Docker Hub?

A quick look at pull requests of well-known AI/ML-related images on Docker Hub shows more than 100 million pull requests. What is driving this level of demand in the AI/ML space? The same things that drive developers to use Docker for any project: accelerating development, streamlining collaboration, and ensuring consistency within projects. 

In this article, we’ll look more closely at how Docker provides a powerful tool for AI/ML development.

As we interact with more development teams who use Docker as part of their AI/ML efforts, we are learning about new and exciting use cases and hearing first-hand how using Docker has helped simplify the process of sharing AI/ML solutions with their teams and other AI/ML practitioners.

Why is Docker the deployment choice for millions of developers when working with AI/ML?

AI/ML development involves managing complex dependencies, libraries, and configurations, which can be challenging and time-consuming. Although these complexities are not limited to AI/ML development, with AI/ML, they can be more taxing on developers. Docker, however, has been helping developers address such issues for 10 years now.

Consistency across environments

Docker allows you to create a containerized environment that includes all the dependencies required for your AI/ML project, including libraries, tools, and frameworks. This environment can be easily shared and replicated across different machines and operating systems, ensuring consistency and reproducibility. Docker images can also be version-controlled and shared via container registries such as Docker Hub, thus enabling seamless collaboration and continuous integration and delivery.

Scalability

Docker provides a lightweight and efficient way to scale AI/ML applications. With Docker, you can run multiple containers on the same machine or across different machines in a cluster, enabling horizontal scaling. This approach can help you handle large datasets, run multiple experiments in parallel, and increase the overall performance of your applications.

Portability

Docker provides portability, allowing you to run your AI/ML applications on any platform that supports Docker, including local machines, cloud-based infrastructures, and edge devices. Docker images can be built once and deployed anywhere, eliminating compatibility issues and reducing the need for complex configurations. This can help you streamline the deployment process and focus on the development of your models.

Reproducibility

Docker enables reproducibility by providing a way to package the entire AI/ML application and its dependencies into a container. This container can be easily shared and replicated, ensuring that experiments are reproducible, regardless of the environment they are run in. Docker provides a way to specify the exact versions of dependencies and configurations needed to reproduce results, which can help validate experiments and ensure reliability and repeatability.

Easy collaboration

Docker makes it easy to collaborate on AI/ML projects with team members or colleagues. Docker images or containers can be easily shared and distributed, ensuring that everyone has access to the same environment and dependencies. This collaboration can help streamline the development process and reduce the time and effort required to set up development environments.

Conclusion

Docker provides a powerful tool for AI/ML development, providing consistency, scalability, portability, reproducibility, and collaboration. By using Docker to package and distribute AI/ML applications and their dependencies, developers can simplify the development process and focus on building and improving their models. 

Check out the Accelerated AI/ML Development page to learn more about how Docker fits into the AI/ML development process.

If you have an interesting use case or story about Docker in your AI/ML workflow, we would love to hear from you and maybe even share your story.

Learn more

Get the latest release of Docker Desktop.

Vote on what’s next! Check out our public roadmap.

Have questions? The Docker community is here to help.

New to Docker? Get started.

Quelle: https://blog.docker.com/feed/

Using Docker Desktop and JFrog Artifactory for the Enterprise

This post, written by our partner JFrog, outlines how to work with JFrog Artifactory and Docker Desktop.

Many companies utilize JFrog Artifactory as a Docker and Helm registry but also utilize Docker Desktop strategically to manage their container services.

In this article, we explain how to configure Docker Desktop to work with JFrog Artifactory as your Docker registry to manage the push and pull of container images across your company’s repositories (such as local, remote, and virtual). We also show how JFrog Artifactory, in conjunction with Docker Desktop, gives users fine-grained control over the movement of Docker images across their portfolio.

Before you begin

For this walkthrough, you’ll need to have the following items already set up:

An active Docker Desktop account through your company

An active trial or subscription to the JFrog Platform

Linking Docker Desktop with JFrog Artifactory

To get started on your Docker Desktop and JFrog software supply chain platform journey, we will assume that Artifactory is your chosen container registry. 

You also may have standardized on Docker Desktop and want to use it as the control plane for moving containers in your organization. To do so, you’ll want to be sure everything is appropriately configured to allow access to Artifactory in the Docker Desktop services. 

The Registry Access Management feature in Docker Desktop helps ensure that only permitted repos and repository types (such as Artifactory local, remote, or virtual repos) are appropriately accessible to be managed by Docker Desktop and that you have applied all permissions according to your company’s access rules. 

A best practice is not to allow unfettered access to your repos and container images, so let’s make sure Artifactory is correctly set up to connect to your selected Docker Desktop services.

Use the following steps to configure Artifactory as an allowed registry in Docker Hub. (These instructions are also found in the official documentation.) Note that the Registry Access Management feature can manage both cloud and on-premises JFrog Artifactory instances.

Sign in to your Docker Hub account as an organization owner.

Select an organization, then navigate to the Settings tab on the Organizations page and select Registry Access Management (Figure 1).

Select Enabled in Registry Access Management to begin setting the permissions for your Artifactory registry.

Add Artifactory to your list by selecting Add and entering your registry details in the applicable field. Then select Create.

Verify that Artifactory appears in your registry list and select Save & Apply.

You can verify that your changes are saved in the Activity tab. Note that you can add unlimited registries.

Figure 1: Configuring JFrog Artifactory as an allowed registry in Docker Hub.

Applying access universally

Next, suppose you want to be sure all your developers using Artifactory cannot mistakenly access certain repos or certain pipelines. To do so, you’ll need to apply access rules across your organization in Docker Desktop. Company IT departments can apply these settings to everyone in your organization, or individual developers can configure this manually, depending on your business rules and operational preferences (as shown in the official docs).

Configure registry.json to enforce sign-in

By default, members of your organization can use Docker Desktop on their machines without signing in to any Docker account. To ensure that a user signs in to a Docker account that is a member of your organization and that the organization’s settings apply to the user’s session, you can use a registry.json file.

The registry.json file is a configuration file that allows administrators to specify the Docker organization the user must belong to. It ensures that your settings apply to the user’s session and can therefore access registries like Artifactory with your company’s rules in place. The Docker Desktop installer reads the `registry.json` for this file on the users’ machines as part of the installation process.

After a registry.json file is configured on a user’s machine, Docker Desktop prompts the user to sign in. If a user doesn’t sign in or tries to sign in using an organization other than the one listed in the registry.json file, they will be denied access to Docker Desktop.

Deploying a registry.json file and forcing users to authenticate is highly recommended but not required. Forced authentication has the following benefits:

Allows administrators to configure features such as Image Access Management, which allows team members to:

Only have access to Trusted Content on Docker Hub

Pull only from the specified categories of images

Authenticated users of Artifactory have unlimited pulls from Docker Hub and do not have to worry about rate limits

Blocks users from accessing Docker Desktop until they are added to a specific organization

Create a registry.json file

Before creating a registry.json file, ensure that the user is a member of at least one organization in Docker Hub. If the registry.json file matches at least one organization the user is a member of, they can sign in to Docker Desktop and access all their organizations.

Based on your operating system, you must create a registry.json file at the following locations and make sure the file can’t be edited by the user:

Windows: /ProgramData/DockerDesktop/registry.json

Mac: /Library/ApplicationSupport/com.docker.docker/registry.json

Linux: /usr/share/docker-desktop/registry/registry.json

The registry.json file must contain the following contents, where myorg is replaced with your organization’s name. The file contents are case-sensitive, and you must use lowercase letters for your organization’s name.

{
"allowedOrgs": ["myorg"]
}

In Docker Hub, you can now download the registry.json file for your organization or copy the specific commands to create the file for your organization. 

To download the file or copy the commands from Docker Hub:

Log in to Docker Hub as an organization owner.

Go to Organizations > Your Organization > Settings.

Select Enforce Sign-in and continue with the on-screen instructions for Windows, Mac, or Linux.

Note: For other methods of creating the registry.json file for your organization based on your operating system, please see the Docker Desktop documentation.

Testing Docker and Artifactory

Now, you need to ensure everything is working properly and that your developers cannot access things they shouldn’t (thereby exposing the business), and that they can also access all the registries they need.

Verify your global changes

After you’ve created the registry.json file and deployed it onto the users’ machines, you can verify whether the access changes have taken effect by asking users to start Docker Desktop to access Artifactory.

If the configuration is successful, Docker Desktop will prompt the user to authenticate using the organization credentials on start. If the user fails to authenticate, they will see an error message, and they will be denied access to Docker Desktop. And, in this case, they will not be able to access Artifactory as their registry.

Give it a test

A quick way to ensure everything is configured correctly is for developers to attempt to access a repository that is not in the allow list that has just been created. If the system won’t allow access to it, you know you did it right. If developers are able to access a non-listed repository, double-check the steps above to ensure all settings are correct.

Conclusion

You’re done! If you’re successful in your setup, your developers and admins should be shown a screen like that in Figure 2, indicating access to both Docker Hub and chosen JFrog Artifactory repos. Now you can use Docker Desktop features to control your registries smoothly, as well as take advantage of unlimited Docker Hub pulls for JFrog customers.

Figure 2: Docker Hub Registry Access Management visualizing Artifactory has successfully been set up as an allowed registry.

Try JFrog for free and get working in minutes with Docker Desktop.

Learn more

Get the latest release of Docker Desktop.

Have questions? The Docker community is here to help.

New to Docker? Get started.

Quelle: https://blog.docker.com/feed/

Optimizing Deep Learning Workflows: Leveraging Stable Diffusion and Docker on WSL 2

Deep learning has revolutionized the field of artificial intelligence (AI) by enabling machines to learn and generate content that mimics human-like creativity. One advancement in this domain is Stable Diffusion, a text-to-image model released in 2022. 

Stable Diffusion has gained significant attention for its ability to generate highly detailed images conditioned on text descriptions, thereby opening up new possibilities in areas such as creative design, visual storytelling, and content generation. With its open source nature and accessibility, Stable Diffusion has become a go-to tool for many researchers and developers seeking to harness the power of deep learning. 

In this article, we will explore how to optimize deep learning workflows by leveraging Stable Diffusion alongside Docker on WSL 2, enabling seamless and efficient experimentation with this cutting-edge technology.

In this comprehensive guide, we will walk through the process of setting up the Stable Diffusion WebUI Docker, which includes enabling WSL 2 and installing Docker Desktop. You will learn how to download the required code from GitHub and initialize it using Docker Compose. 

The guide provides instructions on adding additional models and managing the system, covering essential tasks such as reloading the UI and determining the ideal location for saving image output. Troubleshooting steps and tips for monitoring hardware and GPU usage are also included, ensuring a smooth and efficient experience with Stable Diffusion WebUI (Figure 1).

Figure 1: Stable Diffusion WebUI.

Why use Docker Desktop for Stable Diffusion?

In the realm of image-based generative AI, setting up an effective execution and development environment on a Windows PC can present particular challenges. These challenges arise due to differences in software dependencies, compatibility issues, and the need for specialized tools and frameworks. Docker Desktop emerges as a powerful solution to tackle these challenges by providing a containerization platform that ensures consistency and reproducibility across different systems.

By leveraging Docker Desktop, we can create an isolated environment that encapsulates all the necessary components and dependencies required for image-based generative AI workflows. This approach eliminates the complexities associated with manual software installations, conflicting library versions, and system-specific configurations.

Using Stable Diffusion WebUI

The Stable Diffusion WebUI is a browser interface that is built upon the Gradio library, offering a convenient way to interact with and explore the capabilities of Stable Diffusion. Gradio is a powerful Python library that simplifies the process of creating interactive interfaces for machine learning models.

Setting up the Stable Diffusion WebUI environment can be a tedious and time-consuming process, requiring multiple steps for environment construction. However, a convenient solution is available in the form of Stable Diffusion WebUI Docker project. This Docker image eliminates the need for manual setup by providing a preconfigured environment.

If you’re using Windows and have Docker Desktop installed, you can effortlessly build and run the environment using the docker-compose command. You don’t have to worry about preparing libraries or dependencies beforehand because everything is encapsulated within the container.

You might wonder whether there are any problems because it’s a container. I was anxious before I started using it, but I haven’t had any particular problems so far. The images, models, variational autoencoders (VAEs), and other data that are generated are shared (bind mounted) with my Windows machine, so I can exchange files simply by dragging them in Explorer or in the Files of the target container on Docker Desktop. 

The most trouble I had was when I disabled the extension without backing it up, and in a moment blew away about 50GB of data that I had spent half a day training. (This is a joke!)

Architecture

I’ve compiled a relatively simple procedure to start with Stable Diffusion using Docker Desktop on Windows. 

Prerequisites:

Windows 10 Pro, 21H2 Build 19044.2846

16GB RAM

NVIDIA GeForce RTX 2060 SUPER

WSL 2 (Ubuntu)

Docker Desktop 4.18.0 (104112)

Setup with Docker Compose

We will use the WebUI called AUTOMATIC1111 to utilize Stable Diffusion this time. The environment for these will be constructed using Docker Compose. The main components are shown in Figure 2.

Figure 2: Configuration built using Docker Compose.

The configuration of Docker Compose is defined in docker-compose.yml. We are using a Compose extension called x-base_service to describe the major components common to each service.

To start, there are settings for bind mount between the host and the container, including /data, which loads modes, and /output, which outputs images. Then, we make the container recognize the GPU by loading the NVIDIA driver.

Furthermore, the service named sd-auto:58 runs AUTOMATIC1111, WebUI for Stable Diffusion, within the container. Because there is a port mapping (TCP:7860), between the host and the container in the aforementioned common service settings, it is possible to access from the browser on the host side to the inside of the container.

Getting Started

Prerequisite

WSL 2 must be activated and Docker Desktop installed.

On the first execution, it downloads 12GB of Stable Diffusion 1.5 models, etc. The Web UI cannot be used until this download is complete. Depending on your connection, it may take a long time until the first startup.

Downloading the code

First, download the Stable Diffusion WebUI Docker code from GitHub. If you download it as a ZIP, click Code > Download ZIP and the stable-diffusion-webui-docker-master.zip file will be downloaded (Figure 3). 

Unzip the file in a convenient location. When you expand it, you will find a folder named stable-diffusion-webui-docker-master. Open the command line or similar and run the docker compose command inside it.

Figure 3: Downloading the configuration for Docker Compose from the repository.

Or, if you have an environment where you can use Git, such as Git for Windows, it’s quicker to download it as follows:

git clone https://github.com/AbdBarho/stable-diffusion-webui-docker.git

In this case, the folder name is stable-diffusion-webui-docker. Move it with cd stable-diffusion-webui-docker.

Supplementary information for those familiar with Docker

If you just want to get started, you can skip this section.

By default, the timezone is UTC. To adjust the time displayed in the log and the date of the directory generated under output/txt2img to Japan time, add TZ=Asia/Tokyo to the environment variables of the auto service. Specifically, add the following description to environment:.

auto: &automatic
<<: *base_service
profiles: ["auto"]
build: ./services/AUTOMATIC1111
image: sd-auto:51
environment:
– CLI_ARGS=–allow-code –medvram –xformers –enable-insecure-extension-access –api
– TZ=Asia/Tokyo

Tasks at first startup

The rest of the process is as described in the GitHub documentation. Inside the folder where the code is expanded, run the following command:

docker compose –profile download up –build

After the command runs, the log of a container named webui-docker-download-1 will be displayed on the screen. For a while, the download will run as follows, so wait until it is complete:

webui-docker-download-1 | [DL:256KiB][#4561e1 1.4GiB/3.9GiB(36%)][#42c377 1.4GiB/3.9GiB(37%)]

If the process ends successfully, it will be displayed as exited with code 0 and returned to the original prompt:

…(snip)
webui-docker-download-1 | https://github.com/xinntao/Real-ESRGAN/blob/master/LICENSE
webui-docker-download-1 | https://github.com/xinntao/ESRGAN/blob/master/LICENSE
webui-docker-download-1 | https://github.com/cszn/SCUNet/blob/main/LICENSE
webui-docker-download-1 exited with code 0

If a code other than 0 comes out like the following, the download process has failed:

webui-docker-download-1 | 42c377|OK | 426KiB/s|/data/StableDiffusion/sd-v1-5-inpainting.ckpt
webui-docker-download-1 |
webui-docker-download-1 | Status Legend:
webui-docker-download-1 | (OK):download completed.(ERR):error occurred.
webui-docker-download-1 |
webui-docker-download-1 | aria2 will resume download if the transfer is restarted.
webui-docker-download-1 | If there are any errors, then see the log file. See ‘-l’ option in help/m
an page for details.
webui-docker-download-1 exited with code 24

In this case, run the command again and check whether it ends successfully. Once it finishes successfully, run the command to start the WebUI. 

Note: The following is for AUTOMATIC1111’s UI and GPU specification:

docker compose –profile auto up –build

When you run the command, loading the model at the first startup may take a few minutes. It may look like it’s frozen like the following display, but that’s okay:

webui-docker-auto-1 | LatentDiffusion: Running in eps-prediction mode
webui-docker-auto-1 | DiffusionWrapper has 859.52 M params.

If you wait for a while, the log will flow, and the following URL will be displayed:

webui-docker-auto-1 | Running on local URL: http://0.0.0.0:7860

Now the startup preparation of the Web UI is set. If you open http://127.0.0.1:7860 from the browser, you can see the Web UI. Once open, select an appropriate model from the top left of the screen, write some text in the text field, and select the Generate button to start generating images (Figure 4).

Figure 4: After selecting the model, input the prompt and generate the image.

When you click, the button will be reversed. Wait until the process is finished (Figure 5).

Figure 5: Waiting until the image is generated.

At this time, the log of image generation appears on the terminal you are operating, and you can also check the similar display by looking at the log of the container on Docker Desktop (Figure 6).

Figure 6: 100% indicates that the image generation is complete.

When the status reaches 100%, the generation of the image is finished, and you can check it on the screen (Figure 7).

Figure 7: After inputting “Space Cat” in the prompt, a cat image was generated at the bottom right of the screen.

The created images are automatically saved in the output/txt2img/date folder directly under the directory where you ran the docker compose command.

To stop the launched WebUI, enter Ctrl+C on the terminal that is still running the docker compose command.

Gracefully stopping… (press Ctrl+C again to force)
Aborting on container exit…
[+] Running 1/1
? Container webui-docker-auto-1 Stopped 11.4s
canceled

When the process ends successfully, you will be able to run the command again. To use the WebUI again after restarting, re-run the docker compose command:

docker compose –profile auto up –build

To see the operating hardware status, use the task manager to look at the GPU status (Figure 8).

Figure 8: From the Performance tab of the Windows Task Manager, you can monitor the processing of CUDA and similar tasks on the GPU.

To check whether the GPU is visible from inside the container and to see whether the information comes out, run the nvidia-smi command from docker exec or the Docker Desktop terminal.

root@e37fcc5a5810:/stable-diffusion-webui# nvidia-smi
Mon Apr 17 07:42:27 2023
+—————————————————————————————+
| NVIDIA-SMI 530.41.03 Driver Version: 531.41 CUDA Version: 12.1 |
|—————————————–+———————-+———————-+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA GeForce RTX 2060 S… On | 00000000:01:00.0 On | N/A |
| 42% 40C P8 6W / 175W| 2558MiB / 8192MiB | 2% Default |
| | | N/A |
+—————————————–+———————-+———————-+
+—————————————————————————————+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| 0 N/A N/A 149 C /python3.10 N/A |
+—————————————————————————————+

Adding models and VAEs

If you download a model that is not included from the beginning, place files with extensions, such as .safetensors in stable-diffusion-webui-dockerdataStableDiffusion. In the case of VAE, place .skpt files in stable-diffusion-webui-dockerdataVAE.

If you’re using Docker Desktop, you can view and operate inside on the Files of the webui-docker-auto-1 container, so you can also drag it into Docker Desktop. 

Figure 9 shows the Docker Desktop screen. It says MOUNT in the Note column, and it shares the information in the folder with the container from the Windows host side.

Figure 9: From the Note column, you can see whether the folder is mounted or has been modified.

Now, after placing the file, a link to Reload UI is shown in the footer of the WebUI, so select there (Figure 10).

Figure 10: By clicking Reload UI, the WebUI settings are reloaded.

When you select Reload UI, the system will show a loading screen, and the browser connection will be cut off. When you reload the browser, the model and VAE files are automatically loaded. To remove a model, delete the model file from dataStableDiffusion.

Conclusion

With Docker Desktop, image generation using the latest generative AI environment can be done easier than ever. Typically, a lot of time and effort is required just to set up the environment, but Docker Desktop solves this complexity. If you’re interested, why not take a challenge in the world of generative AI? Enjoy!

Learn more

Get the latest release of Docker Desktop.

Have questions? The Docker community is here to help.

New to Docker? Get started.

Quelle: https://blog.docker.com/feed/

How Kinsta Improved the End-to-End Development Experience by Dockerizing Every Step of the Production Cycle

Guest author Amin Choroomi is an experienced software developer at Kinsta. Passionate about Docker and Kubernetes, he specializes in application development and DevOps practices. His expertise lies in leveraging these transformative technologies to streamline deployment processes and enhance software scalability.

One of the biggest challenges of developing and maintaining cloud-native applications at the enterprise level is having a consistent experience through the entire development lifecycle. This process is even harder for remote companies with distributed teams working on different platforms, with different setups, and asynchronous communication. 

At Kinsta, we have projects of all sizes for application hosting, database hosting, and managed WordPress hosting. We need to provide a consistent, reliable, and scalable solution that allows:

Developers and quality assurance teams, regardless of their operating systems, to create a straightforward and minimal setup for developing and testing features.

DevOps, SysOps, and Infrastructure teams to configure and maintain staging and production environments.

Overcoming the challenge of developing cloud-native applications on a distributed team

At Kinsta, we rely heavily on Docker for this consistent experience at every step, from development to production. In this article, we’ll walk you through:

How to leverage Docker Desktop to increase developers’ productivity.

How we build Docker images and push them to Google Container Registry via CI pipelines with CircleCI and GitHub Actions.

How we use CD pipelines to promote incremental changes to production using Docker images, Google Kubernetes Engine, and Cloud Deploy.

How the QA team seamlessly uses prebuilt Docker images in different environments.

Using Docker Desktop to improve the developer experience

Running an application locally requires developers to meticulously prepare the environment, install all the dependencies, set up servers and services, and make sure they are properly configured. When you run multiple applications, this approach can be cumbersome, especially when it comes to complex projects with multiple dependencies. And, when you introduce multiple contributors with multiple operating systems, chaos is installed. To prevent this, we use Docker.

With Docker, you can declare the environment configurations, install the dependencies, and build images with everything where it should be. Anyone, anywhere, with any OS can use the same images and have exactly the same experience as anyone else.

Declare your configuration with Docker Compose

To get started, you need to create a Docker Compose file, docker-compose.yml. This is a declarative configuration file written in YAML format that tells Docker your application’s desired state. Docker uses this information to set up the environment for your application.

Docker Compose files come in handy when you have more than one container running and there are dependencies between containers.

To create your docker-compose.yml file:

Start by choosing an image as the base for our application. Search on Docker Hub to find a Docker image that already contains your app’s dependencies. Make sure to use a specific image tag to avoid errors. Using the latest tag can cause unforeseen errors in your application. You can use multiple base images for multiple dependencies — for example, one for PostgreSQL and one for Redis.

Use volumes to persist data on your host if you need to. Persisting data on the host machine helps you avoid losing data if Docker containers are deleted or if you have to recreate them.

Use networks to isolate your setup to avoid network conflicts with the host and other containers. It also helps your containers to find and communicate with each other easily.

Bringing it all together, we have a docker-compose.yml that looks like this:

“`yaml
version: ‘3.8’

services:
db:
image: postgres:14.7-alpine3.17
hostname: mk_db
restart: on-failure
ports:
– ${DB_PORT:-5432}:5432
volumes:
– db_data:/var/lib/postgresql/data
environment:
POSTGRES_USER: ${DB_USER:-user}
POSTGRES_PASSWORD: ${DB_PASSWORD:-password}
POSTGRES_DB: ${DB_NAME:-main}
networks:
– mk_network
redis:
image: redis:6.2.11-alpine3.17
hostname: mk_redis
restart: on-failure
ports:
– ${REDIS_PORT:-6379}:6379
networks:
– mk_network

volumes:
db_data:

networks:
mk_network:
name: mk_network
“`

Containerize the application

Build a Docker image for your application

To begin, we need to build a Docker image using a Dockerfile, and then call that from docker-compose.yml.

Follow these five steps to create your Dockerfile file:

1. Start by choosing an image as a base. Use the smallest base image that works for the app. Usually, alpine images are minimal with nearly zero extra packages installed. You can start with an alpine image and build on top of that:

“`docker
FROM node:18.15.0-alpine3.17
“`

2. Sometimes you need to use a specific CPU architecture to avoid conflicts. For example, suppose that you use an arm64-based processor but you need to build an amd64 image. You can do that by specifying the — platform in Dockerfile:

“`docker
FROM –platform=amd64 node:18.15.0-alpine3.17
“`

3. Define the application directory and install the dependencies and copy the output to your root directory:

“`docker
WORKDIR /opt/app
COPY package.json yarn.lock ./
RUN yarn install
COPY . .
“`

4. Call the Dockerfile from docker-compose.yml:

“`yaml
services:
…redis
…db

app:
build:
context: .
dockerfile: Dockerfile
platforms:
– "linux/amd64"
command: yarn dev
restart: on-failure
ports:
– ${PORT:-4000}:${PORT:-4000}
networks:
– mk_network
depends_on:
– redis
– db
“`

5. Implement auto-reload so that when you change something in the source code, you can preview your changes immediately without having to rebuild the application manually. To do that, build the image first, then run it in a separate service:

“`yaml
services:
… redis
… db

build-docker:
image: myapp
build:
context: .
dockerfile: Dockerfile
app:
image: myapp
platforms:
– "linux/amd64"
command: yarn dev
restart: on-failure
ports:
– ${PORT:-4000}:${PORT:-4000}
volumes:
– .:/opt/app
– node_modules:/opt/app/node_modules
networks:
– mk_network
depends_on:
– redis
– db
– build-docker

volumes:
node_modules:
“`

Pro tip: Note that node_modules is also mounted explicitly to avoid platform-specific issues with packages. This means that, instead of using the node_modules on the host, the Docker container uses its own but maps it on the host in a separate volume.

Incrementally build the production images with continuous integration 

The majority of our apps and services use CI/CD for deployment, and Docker plays an important role in the process. Every change in the main branch immediately triggers a build pipeline through either GitHub Actions or CircleCI. The general workflow is simple: It installs the dependencies, runs the tests, builds the Docker image, and pushes it to Google Container Registry (or Artifact Registry). In this article, we’ll describe the build step.

Building the Docker images

We use multi-stage builds for security and performance reasons.

Stage 1: Builder

In this stage, we copy the entire code base with all source and configuration, install all dependencies, including dev dependencies, and build the app. It creates a dist/ folder and copies the built version of the code there. This image is way too large, however, with a huge set of footprints to be used for production. Also, as we use private NPM registries, we use our private NPM_TOKEN in this stage as well. So, we definitely don’t want this stage to be exposed to the outside world. The only thing we need from this stage is the dist/ folder.

Stage 2: Production

Most people use this stage for runtime because it is close to what we need to run the app. However, we still need to install production dependencies, and that means we leave footprints and need the NPM_TOKEN. So, this stage is still not ready to be exposed. Here, you should also note the yarn cache clean on line 19. That tiny command cuts our image size by up to 60 percent.

Stage 3: Runtime

The last stage needs to be as slim as possible with minimal footprints. So, we just copy the fully baked app from production and move on. We put all those yarn and NPM_TOKEN stuff behind and only run the app.

This is the final Dockerfile.production:

“`docker
# Stage 1: build the source code
FROM node:18.15.0-alpine3.17 as builder
WORKDIR /opt/app
COPY package.json yarn.lock ./
RUN yarn install
COPY . .
RUN yarn build

# Stage 2: copy the built version and build the production dependencies FROM node:18.15.0-alpine3.17 as production
WORKDIR /opt/app
COPY package.json yarn.lock ./
RUN yarn install –production && yarn cache clean
COPY –from=builder /opt/app/dist/ ./dist/

# Stage 3: copy the production ready app to runtime
FROM node:18.15.0-alpine3.17 as runtime
WORKDIR /opt/app
COPY –from=production /opt/app/ .
CMD ["yarn", "start"]
“`

Note that, for all the stages, we start copying package.json and yarn.lock files first, installing the dependencies, and then copying the rest of the code base. The reason for this is that Docker builds each command as a layer on top of the previous one, and each build could use the previous layers if available and only build the new layers for performance purposes. 

Let’s say you have changed something in src/services/service1.ts without touching the packages. That means the first four layers of the builder stage are untouched and could be reused. This approach makes the build process incredibly faster.

Pushing the app to Google Container Registry through CircleCI pipelines

There are several ways to build a Docker image in CircleCI pipelines. In our case, we chose to use circleci/gcp-gcr orbs:

Minimum configuration is needed to build and push our app, thanks to Docker.

“`yaml
executors:
docker-executor:
docker:
– image: cimg/base:2023.03
orbs:
gcp-gcr: circleci/gcp-gcr@0.15.1
jobs:
…
deploy:
description: Build & push image to Google Artifact Registry
executor: docker-executor
steps:
…
– gcp-gcr/build-image:
image: my-app
dockerfile: Dockerfile.production
tag: ${CIRCLE_SHA1:0:7},latest
– gcp-gcr/push-image:
image: my-app
tag: ${CIRCLE_SHA1:0:7},latest
“`

Pushing the app to Google Container Registry through GitHub Actions

As an alternative to CircleCI, we can use GitHub Actions to deploy the application continuously.

We set up gcloud and build and push the Docker image to gcr.io:

“`yaml
jobs:
setup-build:
name: Setup, Build
runs-on: ubuntu-latest

steps:
– name: Checkout
uses: actions/checkout@v3

– name: Get Image Tag
run: |
echo "TAG=$(git rev-parse –short HEAD)" >> $GITHUB_ENV

– uses: google-github-actions/setup-gcloud@master
with:
service_account_key: ${{ secrets.GCP_SA_KEY }}
project_id: ${{ secrets.GCP_PROJECT_ID }}

– run: |-
gcloud –quiet auth configure-docker

– name: Build
run: |-
docker build
–tag "gcr.io/${{ secrets.GCP_PROJECT_ID }}/my-app:$TAG"
–tag "gcr.io/${{ secrets.GCP_PROJECT_ID }}/my-app:latest"
.

– name: Push
run: |-
docker push "gcr.io/${{ secrets.GCP_PROJECT_ID }}/my-app:$TAG"
docker push "gcr.io/${{ secrets.GCP_PROJECT_ID }}/my-app:latest"
“`

With every small change pushed to the main branch, we build and push a new Docker image to the registry.

Deploying changes to Google Kubernetes Engine using Google Delivery Pipelines

Having ready-to-use Docker images for each and every change also makes it easier to deploy to production or roll back in case something goes wrong. We use Google Kubernetes Engine to manage and serve our apps, and we use Google Cloud Deploy and Delivery Pipelines for our continuous deployment process.

When the Docker image is built after each small change (with the CI pipeline shown previously), we take one step further and deploy the change to our dev cluster using gcloud. Let’s look at that step in CircleCI pipeline:

“`yaml
– run:
name: Create new release
command: gcloud deploy releases create release-${CIRCLE_SHA1:0:7} –delivery-pipeline my-del-pipeline –region $REGION –annotations commitId=$CIRCLE_SHA1 –images my-app=gcr.io/${PROJECT_ID}/my-app:${CIRCLE_SHA1:0:7}
“`

This step triggers a release process to roll out the changes in our dev Kubernetes cluster. After testing and getting the approvals, we promote the change to staging and then production. This action is all possible because we have a slim isolated Docker image for each change that has almost everything it needs. We only need to tell the deployment which tag to use.

How the Quality Assurance team benefits from this process

The QA team needs mostly a pre-production cloud version of the apps to be tested. However, sometimes they need to run a prebuilt app locally (with all the dependencies) to test a certain feature. In these cases, they don’t want or need to go through all the pain of cloning the entire project, installing npm packages, building the app, facing developer errors, and going over the entire development process to get the app up and running.

Now that everything is already available as a Docker image on Google Container Registry, all the QA team needs is a service in Docker compose file:

“`yaml
services:
…redis
…db

app:
image: gcr.io/${PROJECT_ID}/my-app:latest
restart: on-failure
ports:
– ${PORT:-4000}:${PORT:-4000}
environment:
– NODE_ENV=production
– REDIS_URL=redis://redis:6379
– DATABASE_URL=postgresql://${DB_USER:-user}:${DB_PASSWORD:-password}@db:5432/main
networks:
– mk_network
depends_on:
– redis
– db
“`

With this service, the team can spin up the application on their local machines using Docker containers by running:

“`shell
docker compose up
“`

With this service, the team can spin up the application on their local machines using Docker containers by running:

“`shell
docker compose up
“`

This is a huge step toward simplifying testing processes. Even if QA decides to test a specific tag of the app, they can easily change the image tag on line 6 and re-run the Docker compose command. Even if they decide to compare different versions of the app simultaneously, they can easily achieve that with a few tweaks. The biggest benefit is to keep our QA team away from developer challenges.

Advantages of using Docker

Almost zero footprints for dependencies: If you ever decide to upgrade the version of Redis or PostgreSQL, you can just change one line and re-run the app. There’s no need to change anything on your system. Additionally, if you have two apps that both need Redis (maybe even with different versions) you can have both running in their own isolated environment, without any conflicts with each other.

Multiple instances of the app: There are many cases where we need to run the same app with a different command, such as initializing the DB, running tests, watching DB changes, or listening to messages. In each of these cases, because we already have the built image ready, we just add another service to the Docker compose file with a different command, and we’re done.

Easier testing environment: More often than not, you just need to run the app. You don’t need the code, the packages, or any local database connections. You only want to make sure the app works properly, or need a running instance as a backend service while you’re working on your own project. That could also be the case for QA, Pull Request reviewers, or even UX folks who want to make sure their design has been implemented properly. Our Docker setup makes it easy for all of them to take things going without having to deal with too many technical issues.

Learn more

Get the latest release of Docker Desktop.

Have questions? The Docker community is here to help.

New to Docker? Get started.

Visit the Kinsta site to learn about the cloud platform.

Quelle: https://blog.docker.com/feed/