Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Use Docker

DZone's Guide to

How to Use Docker

Containers are lightweight and convenient, but require certain knowledge to manage. Learn more about successfully orchestrating Docker container deployments.

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

Docker is on a roll. In the last few years, this container management service has become immensely popular in development, especially given the great fit with agile-based projects and continuous delivery. In this article, I want to take a brief look at how you can use Docker to accelerate and streamline the software development lifecycle (SDLC) process.

First, however, a brief introduction. The whole concept of Docker is for developers to easily ship applications inside "software containers" which can then be deployed and run anywhere. Let’s imagine you develop an application on your laptop where it works perfectly. Then you push that into a test or production environment; you’ve chosen the right stack, the right language, and right version. But it doesn’t work. Why? Because it’s not the same environment.

Maybe you used a new version of a library, but the ops guy tells you that you can’t use this library because all the other applications running on the server will break. So, there’s a lot of back and forth between the ops and your team of developers. It delays projects, costs money and is frustrating for everyone involved.

When you develop with Docker, everything is packaged inside a container, or inside several containers that talk to each other. Docker completely isolates your piece of software from any external dependencies. A container is self-sufficient. You simply push the container to another environment; its contents and how it was developed are transparent to the ops team. So how is a "software container" like this any different from a standalone computer? Or a virtual machine for that matter?

Containers are lightweight because they don’t need the extra load of a hypervisor, but run directly within the host machine’s kernel. This means you can run more containers on a given hardware combination than if you were using virtual machines. You can even run Docker containers within host machines that are actually virtual machines. All of this makes containers – and Docker – ideal for continuous integration and continuous delivery workflows.

Docker itself uses a client-server architecture. The client talks to the daemon, which does the heavy lifting of building, running and distributing the containers. The Docker client and daemon can run on the same system, or you can connect the client to a remote daemon. The Docker client and daemon communicate using a REST API, over UNIX sockets or a network interface.

Orchestrating the Management and Deployment of Docker Containers

Despite all its advantages, Docker still requires its own platform to be managed, someone to manage build, run, assign and stop the containers (as well many additional administrative tasks). And Docker itself still needs to be aware of the other environments it interacts with, including the infrastructure layer and other traditional software services not currently running within the container landscape. Time spent by developers on tasks like these is considered an overhead which can result in missed deadlines, while time spent by ops performing these tasks creates pipeline bottlenecks right before production deployments, which can, in turn, lead to production failures.

There is a solution that enables you to orchestrate all the moving parts – people, process, and technology – involved in managing and deploying to Docker containers. Release automation packages. The built in Automic container blueprint provisioning system along with the Docker actionpack from Automic allows you to blueprint entire Docker systems, build visual workflows and automate container builds, maintenance, provisioning, configurations and most administration tasks. This not only increases productivity among developers and administrators, it also lowers the risk of errors occurring. One example might be automatically ensuring the underlying infrastructure has enough capacity to support the projected container workloads or that certain container versions are always rolled out with matching external service package versions.

The Docker environment blueprint provisioning capability and actionpack from Automic combines an integrated application packaging system, smart deployment models, and out-of-the-box actions for common deployment tasks with robust workflow design and high-volume execution capability. The Automic Docker package allows users to build, provision, configure and manage Docker containers as part of an automated application deployment process.

Ultimately, this accelerates deployments to Docker containers, ensures the quality of container deployments and minimizes management overhead to help both development and operations grow the business.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
docker ,devops ,containers ,continuous delivery

Published at DZone with permission of Ron Gidron, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}