Kategorie: Kubernetes

Using Docker Desktop and Docker Hub Together – Part 1

Introduction

In today’s fast-paced development world CTOs, dev managers and product managers demand quicker turnarounds for features and defect fixes. “No problem, boss,” you say. “We’ll just use containers.” And you would be right but once you start digging in and looking at ways to get started with containers, well quite frankly, it’s complex. 

One of the biggest challenges is getting a toolset installed and setup where you can build images, run containers and duplicate a production kubernetes cluster locally. And then shipping containers to the Cloud, well, that’s a whole ‘nother story.

Docker Desktop and Docker Hub are two of the foundational toolsets to get your images built and shipped to the cloud. In this two-part series, we’ll get Docker Desktop set up and installed, build some images and run them using Docker Compose. Then we’ll take a look at how we can ship those images to the cloud, set up automated builds, and deploy our code into production using Docker Hub.

Docker Desktop

Docker Desktop is the easiest way to get started with containers on your development machine. The Docker Desktop comes with the Docker Engine, Docker CLI, Docker Compose and Kubernetes. With Docker Desktop there are no cloning of repos, running make files and searching StackOverflow to help fix build and install errors. You just need to download the image for your OS and double-click to get started installing. Let’s quickly walk through the process now.

Installing Docker Desktop

Docker Desktop is available for Mac and Windows. Navigate over to Docker Desktop homepage and choose your OS.

Once the download has completed, double click on the image and follow the instructions to get Docker Desktop installed. For more information on installing for your specific operating system, click the link below.

Install Docker Desktop on MacInstall Docker Desktop on Windows

Docker Desktop UI Overview

Once you’ve downloaded and installed Docker Desktop and the whale icon has become steady you are all set. Docker Desktop is running on your machine.

Dashboard

Now, let’s open the docker dashboard and take a look around.

Click on the Docker icon and choose “Desktop” from the dropdown menu.

The following window should open:

As you can see, we do not have any containers running at this time. We’ll fix that in a minute but for now, let’s take a quick tour of the dashboard.

Login with Docker ID

The first thing we want to do is login with our Docker ID. If you do not already have a one, head over to Docker Hub and signup. Go ahead, I’ll wait.

Okay, in the top right corner of the Dashboard, you’ll see the Sign in button. Click on that and enter your Docker ID and Password. If instead, you see your Docker ID, then you are already logged in.

Settings

Now let’s take a look at the settings you can configure in Docker Desktop. Click on the settings icon in the upper right hand corner of the window and you should see the Settings screen:

General

Under this tab is where you’ll find the general settings such as starting Docker Desktop when you log in to your machine, automatically checking for updates, include the Docker Desktop VM in backups, and whether Docker Desktop will send usage statistics to Docker.

These default settings are fine. You really do not need to change them unless you are doing advanced image builds and need to backup your working images. Or you want to have more control over when Docker Desktop is started.

Resources

Next let’s take a look at the Resources tab. On this tab and its sub-tabs is where you can control the resources that are allocated to your Docker environment. These default settings are sufficient to get started. If you are building a lot of images or running a lot of containers at once, you might want to bump up the number of CPUs, Memory and RAM. You can find more information about these settings in our documentation.

Docker Engine

If you are looking to make more advanced changes to the way the Docker Engine runs, then this is the tab for you. The Docker Engine daemon is configured using a daemon.json file located in /etc/docker/daemon.json on Linux systems. But when using Docker Desktop, you will add the config settings here in the text area provided. These settings will get passed to the Docker Engine that is used with Docker Desktop. All available configurations can be found in the documentation.

Command Line

Turning on and off experimental features for the CLI is as simple as toggling a switch. These features are for testing and feedback purposes only. So don’t rely on them for production. They could be changed or removed in future builds.

You can find more information about what experimental features are included in your build on this documentation page.

Kubernetes

Docker Desktop comes with a standalone Kubernetes server and client and is integrated with the Docker CLI. On this tab is where you can enable and disable this Kubernetes. This instance of Kubernetes is not configurable and comes with one single-node cluster.

The Kubernetes server runs within a Docker container and is intended for local testing only. When Kubernetes support is enabled, you can deploy your workloads, in parallel, on Kubernetes, Swarm, and as standalone containers. Enabling or disabling the Kubernetes server does not affect your other workloads.

Troubleshoot

Let’s move on to the troubleshoot screen. Click on the but icon in the upper right hand corner of the window and you should see the following Troubleshoot screen:

Here is where you can restart Docker Desktop, Run Diagnostics, Reset features and Uninstall Docker Desktop.

Building Images and Running Containers

Now that we have Docker Desktop installed and have a good overview of the UI, let’s jump in and create a Docker image that we can run and ship to Hub.

Docker consists of two major components: the Engine that runs as a daemon on your system and a CLI that sends commands to the daemon to build, ship and run your images and containers.

In this article, we will be primarily interacting with Docker through the CLI.

Difference between Images and Containers

A container is a process running on your system just like any other process. But the difference between a “container” process and a “normal” process is that the container process has been sandboxed or isolated from other resources on the system. 

One of the main pieces of this isolation is the filesystem. Each container is given its own private filesystem which is created from the Docker image. This Docker image is where everything is packaged for the processes to run – code, libraries, configuration files, environment variables and runtime.

Creating a Docker Image

I’ve put together a small node.js application that I’ll use for demonstration purposes but any web application would follow the same principles that we will be talking about. Feel free to use your own application and follow along.

First, let’s clone the application from GitHub.

$ git clone git@github.com:pmckeetx/projectz.git

Open the project in your favorite text editor. You’ll see that the application is made up of a UI written in React.js and a backend service written in Node.js and Express.

Let’s install the dependencies and run the application locally to make sure everything is working.

Open your favorite terminal and cd into the root directory of the project.

$ cd services

$ npm install 

Now let’s install the UI dependencies.

$ cd ../ui

$ npm install

Let’s start the services project first. Open a new terminal window and cd into the services directory. To run the application execute the following command:

$ npm run start

In your original terminal window, start the UI. To start the UI run the following command:

$ npm run start

If a browser window is not opened for you automatically, fire up your favorite browser and navigate to http://localhost:3000/

You should see the following screen:

If you do not see a list of projects or get an error message, make sure you have the services project running.

Okay, great, we have everything set up and running.

Dockerfile

Before we build our images, let’s take a quick look at the Dockerfile we’ll use to build the services image.

In your texteditor, open the Dockerfile for the services project. You should see the following.

FROM node:lts

ARG NODE_ENV=production
ENV NODE_ENV $NODE_ENV

WORKDIR /code

ARG PORT=80
ENV PORT $PORT

COPY package.json /code/package.json
COPY package-lock.json /code/package-lock.json
RUN npm ci

COPY . /code

CMD [ “node”, “src/server.js” ]

A Dockerfile is basically a shell script that tells Docker how to build your image.

FROM node:lts

The first line in the file tells Docker that we will be using the long-term-support of node.js as our base image.

ARG NODE_ENV=production
ENV NODE_ENV $NODE_ENV

Next, we create a build arg and set the default value to be “production” and then set NODE_ENV environment variable to what was set in the NODE_ENV build arg.

WORKDIR /code

Now we tell Docker to create a directory named code and use it as our working directory. The following COPY and RUN commands will be performed in this directory:

ARG PORT=80
ENV PORT $PORT

Here we are creating another build argument and assigning 80 as the value. Then this build argument is used to set the PORT environment variable.

COPY package.json /code/package.json
COPY package-lock.json /code/package-lock.json
RUN npm ci

These COPY commands will copy the package*.json files into our image and will be used by the npm ci to install node.js dependencies.

COPY . /code

Now we’ll copy our application code into the image.

Quick Note: Dockerfiles are executed from top to bottom. Each command will first be checked against a cache. If nothing has changed in the cache, Docker will use the cache instead of running the command. On the other hand, if something has changed, the cache will be invalidated and all subsequent cache layers will also be invalidated and corresponding commands will be run. So if we want to have the fastest build possible and not invalidate the entire cache on every image build, we will want to place the commands that change the most as far to the bottom of the Dockerfile as possible.

So for example, we want to copy the package.json and package-lock.json files into the image before we copy the source code because the source code will change a lot more often than adding modules to the package.json file. 

CMD [ “node”, “src/server.js” ]

The last line in our Dockerfile tells Docker what command we would like to execute when our image is started. In this case, we want to execute the command: node src/server.js

Building the image

Now that we understand our Dockerfile. Let’s have Docker build the image.

In the root of the services directory, run the following command:

$ docker build –tag projectz-svc .

This tells Docker to build our image using the Dockerfile located in the current directory and then tag that image with projectz-svc

You should see a similar output when Docker has finished building the image.

Successfully built 922d1db89268

Successfully tagged projectz-svc

Now let’s run our container and make sure we can connect to it. Run the following command to start our image and connect port 8080 to port 80 inside our container.

$ docker run -it –rm –name services -p 8080:80 projectz-svc

You should see the following printed to the terminal:

Listening on port: 80

Open your browser and navigate to http://localhost:8080/services/projects

If all is well, you will see a bunch of json returned in the browser and “GET /services/projects” printed on in the terminal.

Let’s do the same for the front-end UI. I won’t walk you through the Dockerfile at this time but we will revisit when we look at pushing to the Cloud.

Navigate in your terminal into the UI source directory and run the following commands:

$ docker build –tag projectz-ui .

$ docker run -it –rm –name ui -p 3000:80 projectz-ui

Again, open your favorite browser and navigate to http://localhost:3000/

Awesome!!!

Now, if you remember at the beginning of the article we took a look at the Docker Desktop UI. At that time we did not have any containers running. Open the Docker Dashboard by clicking on the whale icon () either in the Notification area (or System Tray) on Windows or from the menu bar on Mac.

We can now see our two containers running:

If you do not see them running, re-run the following commands in your terminal.

$ docker run -it –rm –name services -p 8080:80 projectz-svc

$ docker run -it –rm –name ui -p 3000:80 projectz-ui

Hover your mouse over one of the images and you’ll see buttons appear.

With these buttons you can do the following:

Open in a browser – If the container exposes a port, you can click this button and open your application in a browser.CLI – This button will run the docker exec in a terminal for you.Stop/Start – You can start and stop your container.Restart – You are also able to restart your container.Delete – You can also remove your container.

Now click on the ui container to view its details page.

On the details screen, we are able to view the container logs, inspect the container, and view stats such as CPU Usage, Memory Usage, Disk Read/Writes, and Networking I/O.

Docker-compose

Now let’s take a look at how we can do this a little easier using docker-compose. Using docker-compose, we can configure both our applications in one file and start both of them with one command.

If you take a look in the root of our git repo, you’ll see a docker-compose.yml file. Open that file in your text editor and let’s have a look.

version: “3.7”

services:

ui:
image: projectz-ui
build:
context: ./ui
args:
NODE_ENV: production
REACT_APP_SERVICE_HOST: http://localhost:8080
ports:
– “3000:80″

services:
image: projectz-svc
build:
context: ./services
args:
NODE_ENV: production
PORT: “80”
ports:
– “8080:80″

This file combines all the parameters we passed to our two earlier commands to build and run our services.

If you have not done so already, stop and remove the services and ui containers that we start earlier.

$ docker stop services

$ docker stop ui

Now let’s start our application using docker-compose. Make sure you are in the root of the git repo and run the following command:

$ docker-compose up –build

Docker-compose will build our images and tag them. Once that is finished, compose will start two containers – one for the UI application and one for the services application.

Open up the Docker Desktop dashboard screen and you will now be able to see we have projectz running.

Expand the projectz and you will see our two containers running:

If you click on either one of the containers, you will have access to the same details screens as before.

Docker-compose gives us huge improvements over running each individual docker build and docker run commands as before. Just imagine if you had 10s of services or even 100s of micro-services running your application and having to start each individual container one at a time. With docker-compose, you can configure your application, build arguments and start all services with one command.

Next Steps

For more on how to use Docker Desktop, check out these resources: 

Docker OverviewGetting started tutorial

Stay tuned for Part II of this series where we’ll use Docker Hub to build our images, run automated tests, and push our images to the cloud.

The post Using Docker Desktop and Docker Hub Together – Part 1 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

A New Way to Get Started with Docker!

One of the most common challenges we hear from developers is how getting started with containers can sometimes feel daunting. It’s one of the needs Docker is focusing on in its commitment to developers and dev teams. Our two aims: teach developers and help accelerate their onboarding.

With the benefits of Docker so appealing, many developers are eager to get something up and running quickly. That’s why, with Docker Desktop Edge 2.2.3 Release, we have launched a brand new “Quick Start” guide which displays after first installation and shows users the Docker basics: how to quickly clone, build, run, and share an image directly in Docker Desktop. 

To keep everything in one place, we’ve crafted the guide with a built-in terminal so that you can paste commands directly — or type them out yourself. It’s a light-touch and integrated way to get something up and running.

Continue learning in an in-depth tutorial

You might expect that this new container you’ve spun up would be just a run-of-the-mill “hello world”. Instead, we’re providing you with a resource for further hands-on learning that you can do at your own pace.

This Docker tutorial, accessible on your localhost, will walk you through the steps to build and share a containerized app. You’ll learn how to build images, use volumes to persist data and mount in source code, and define your application using Compose. We’ll also delve deeper into a few useful advanced topics like networking and image building best-practices.

You’ll be on your way to developing with containers with confidence! 

Feedback

To try out the new guide, download the latest version of Docker Desktop and send us any feedback or ideas for other kinds of tutorials you’d like to see in our Roadmap here.

Download the latest Docker Desktop Edge 2.2.3 Release!

Edge 2.2.3 for macOS

Edge 2.2.3 for Windows
The post A New Way to Get Started with Docker! appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

How we test Docker Desktop with WSL 2

Recently we have released a new Edge version 2.2.3.0 of Docker Desktop for Windows. This can be considered as a release candidate for the next Stable version that will officially support WSL 2. With Windows 10 version 2004 in sight we are giving the next version of Docker Desktop the final touches to give you the best experience running Linux containers on Windows 10.

One of the great benefits is that with the next update of Windows 10 we will also support running Docker Desktop on Windows 10 Home. We worked closely with Microsoft during the last few months to make Docker Desktop and WSL 2 fit together.

In this blog post we look behind the scenes at how we set up new WSL 2 capable test machines to run automated tests in our CI pipeline.

It started with a laptop

Let’s keep in mind that all automation somehow starts with manual steps and you evolve from there to get better and more automated. At the beginning of this project we were given a laptop back at KubeCon 2019 with an early version of WSL 2.

With that single laptop our development team could start getting their hands on that new feature and integrating it into Docker Desktop. But of course, this doesn’t really scale for a whole team and we also needed automated tests.

The Docker Desktop test matrix

In the Docker Desktop team we run several test suites across several Windows and Mac machines with different operating system versions installed. Each code change is tested with a matrix of tests on selected machines.

One of our challenges was to add Windows machines to this matrix with WSL 2 enabled. At that time the Windows Insider program started to ship first releases and we could start automating the process to keep new test machines up to date.

On-demand test runners

The startup time of Docker Desktop is much faster with the WSL 2 backend. This gave us the option to run the end-to-end tests in virtual machines. We enhanced our CI infrastructure to spin up Windows 10 Insider machines in Azure on demand. This gave us more flexibility to keep the test machines at a working version of WSL 2 in our pool and also trying out the latest Insider builds.

Our internal CI dashboard shows all the test machines and the jobs running on them changed every few weeks. We constantly moved from one Insider release to the next. Currently we are concentrating on the final Slow Ring builds 19041.x, but we are also continuing with the next Fast Ring machines to have feedback from upcoming Windows builds.

Automated pipeline to build the test machines

The Azure VM images we use to spin up WSL 2 test machines are created with a separate CI pipeline. We use Packer to create the VM image from an ISO file and run provision scripts to prepare everything we need to run it as a CI runner. The pipeline of how we build and upload the VM image also contains more than just the build step. We first check the source code of the Packer template and the PowerShell and Unix shell scripts to fail fast if a code change broke something. The Packer build itself takes the longest time, it also runs a Windows Update in the VM to get the latest OS version. After the build we added a verification step using InSpec to check if the software we need is installed correctly.

The output of this Packer pipeline is an Azure VM image that can be used to spin up new on-demand runners in other CI pipelines. We normally run some tests in a canary environment to see if the VM image really boots up and attaches to our CI infrastructure. If everything is fine we update the configuration for the Docker Desktop CI for our end-to-end tests.

A new challenge: Windows 10 Home

With that automation for Windows 10 Pro machines at hand we were able to add Windows 10 Home very easily. Of course there were some challenges, for example Windows 10 Home does not provide Remote Desktop support. We added a VNC server to be able to attach to the cloud runners if we want to investigate problems.

Conclusion

In the last 12 months the Docker Desktop team worked hard to bring not only the WSL 2 support to Docker Desktop, but also enabled Windows 10 Home users to easily run Docker on their machines. We really look forward to the official release of Windows 10, version 2004 and love to hear your feedback.
The post How we test Docker Desktop with WSL 2 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

#mydockerbday Recap + Community Stories

Emma Cresta, 13

Although March has come and gone, you can still take part in the awesome activities put together by the community to celebrate Docker’s 7th birthday. 

Birthday Challenge

Denise Rey and Captains Łukasz Lach, Marcos Nils, Elton Stoneman, Nicholas Dille, and Brandon Mitchell put together an amazing birthday challenge for the community to complete and it is still available. If you haven’t checked out the hands-on learning content yet, go to the birthday page and earn your seven badges (and don’t forget to share them on twitter).

Live Show

Captain Bret Fisher hosted a 3-hour live Birthday Show with the Docker team and Captains. You can check out the whole thing on Docker’s Youtube Channel, or skip ahead using the timestamps below:

– 02:00 Pre-show pics and games

– 07:43 Kickoff with Captains

– 29:00 Docker Roadmap

– 1:15:47 Docker Desktop: What’s New

– 1:53:45 Docker Hub with GitHub Actions

– 2:20:15 Using Docker with Kubernetes

– 2:55:00 #myDockerBday Stories

Community Stories

And while many Community Leaders had to cancel in-person meetups due to the evolving COVID 19 situation, they and their communities still showed up and shared their #mydockerbday stories. There were too many amazing stories to include in one blog post, so I’ve shared just a few of my favorites here: 

Joining a microservice-based architecture team was already going to be a steep learning curve. That would have been the case if it wasn’t for Docker. Learning and using Docker was a very pleasant experience and has improved my day-to-day developer experience because it makes everything easy, especially on projects that span multiple services. I am truly grateful for this product.

Gerade Geldenhuys, Engineer

I first stumbled upon Docker at a conference and I have been a big fan ever since. The concept of a container and the ease of using it was great. I would actively attend meetups on Docker and also hosted a Docker meetup along with co-workers. I have also made a few OSS contributions to Docker and had fun learning Golang in the process. Docker fascinates me today as much as it did 7 years ago. #myDockerBday

Deepak Bhaskaran, Engineer

Well, I’m from Porto Alegre, but today I live in Ireland. I learned everything Docker from the Porto Alegre community led by Cristiano and I also made great friends there. Today I work a lot using Docker (I’m a Freelancer) and I also help other women and black people to enter the infrastructure and development area using Docker. And last but not least, on Docker’s birthday last year I met a wonderful person who today is my husband (my husband is an excellent person, but loves to break production). Thank you for bringing me great friends and the love of my life.

Natalia Raythz, Developer

I use Docker everyday, since 2014, from Docker v0.9. I containerized all of my applications, speeding up my CI / CD with Docker.

Jintao Zhang, Engineer
The post #mydockerbday Recap + Community Stories appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Deploy Stateful Docker Containers with Amazon ECS and Amazon EFS

At Docker, we are always looking for ways to make developers’ lives easier either directly or by working with our partners. Improving developer productivity is a core benefit of using Docker products and recently one of our partners made an announcement that makes developing cloud-native apps easier.

AWS announced that its customers can now configure their Amazon Elastic Container Service (ECS) applications deployed in Amazon Elastic Compute Cloud (EC2) mode to access Amazon Elastic File Storage (EFS) file systems. This is good news for Docker developers who use Amazon ECS. It means that Amazon ECS now natively integrates with Amazon EFS to automatically mount shared file systems into Docker containers. This allows you to deploy workloads that require access to shared storage such as machine learning workloads, containerizing legacy apps, or internal DevOps workloads such as GitLab, Jenkins, or Elasticsearch. 

The beauty of containerizing your applications is to provide a better way to create, package, and deploy software across different computing environments in a predictable and easy-to-manage way. Containers were originally designed to be stateless and ephemeral (temporary). A stateless application is one that neither reads nor stores information about its state from one time that it is run to the next. A stateful application, on the other hand, can remember some things about its state each time it runs.

Maintaining state in an app means finding a way to connect containers to stateful storage. For example, if you open up your weather app on your mobile device, it remembers your home city as the weather app maintains state. The only way to containerize applications that require state is to connect containers to stateful, persistent storage.

“Docker and AWS are collaborating on making the right workloads more easily deployed as stateful containerized applications. Docker’s industry-leading container technology including Docker Desktop and Docker Hub are integral to advancing developer workflows for modern apps. Our customers can now deploy and run Docker containers seamlessly on Amazon ECS and Amazon EFS, enabling development teams to ship apps faster,” according to Justin Graham, Vice President of Products for Docker.

If you are a developer who would like to deploy workloads that require access to shared external storage, highly-available regional storage, or high-throughput storage then the combination of Amazon ECS and Amazon EFS is your answer. Developers familiar with Amazon ECS can now use the ECS task definition to specify the file system ID and specific directory that they would like to mount on one or more containers in their task. ECS takes care of mounting the file-system on the container so that you can focus on your applications without having to worry about configuring infrastructure. 

If you are interested in how to actually deploy a stateful container-based application, AWS’ Martin Beeby has a great blog post that walks through how to configure Amazon EFS to add state to your containers running on Amazon ECS. Developers who are interested in learning more about how to get started with Docker can expand their understanding with these additional resources: Docker Desktop and Docker Hub.

The post Deploy Stateful Docker Containers with Amazon ECS and Amazon EFS appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Announcing the Compose Specification

Docker is pleased to announce that we have created a new open community to develop the Compose Specification. This new community will be run with open governance with input from all interested parties allowing us together to create a new standard for defining multi-container apps that can be run from the desktop to the cloud. 

Docker is working with Amazon Web Services (AWS), Microsoft and others in the open source community to extend the Compose Specification to more flexibly support cloud-native platforms like Kubernetes and Amazon Elastic Container Service (Amazon ECS) in addition to the existing Compose platforms. Opening the specification will allow innovation to flourish and deliver more choices to developers, accelerating how development teams build and ship applications.

Currently used by millions of developers and with over 650,000 Compose files on GitHub, Compose has been widely embraced by developers because it is a simple cloud and platform-agnostic way of defining multi-container based applications. Compose dramatically simplifies the code to cloud process and toolchain for developers by allowing them to define a complex stack in a single file and run it with a single command. This eliminates the need to build and start every container manually, saving development teams valuable time.

Previously Compose did not have a published specification, and was tied to the implementation, and to specifics of the platforms it shipped on. Open governance will benefit the wider community of new and existing users with transparency and the ability to have input into the future direction of the specification and Compose based tools. With greater community support and engagement, Docker intends to submit the Compose Specification to an open source foundation to further enhance the level playing field and openness.

If you want to get started using Docker Compose today to try the existing features you can download Docker Desktop with Docker Compose here. Or if you are looking for some examples or ideas to get started with Compose why not check out the Awesome Compose Repo. The draft specification is available at compose-spec.io; we are looking for contributors to the Compose Specification along with people who are interested in building tools around the specification. Docker will continue to contribute to the specification and be an active member of the community around it going forward.
The post Announcing the Compose Specification appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/