This post was originally published on this site

Modern applications can come in many flavors, consisting of different technology stacks and architectures, from n-tier to microservices and everything in between. Regardless of the application architecture, the focus is shifting from individual containers to a new unit of measurement which defines a set of containers working together – the Docker Application. We first introduced Docker Application packages a few months ago. In this blog post, we look at what’s driving the need for these higher-level objects and how Docker Enterprise 3.0 begins to shift the focus to applications.

Scaling for Multiple Services and Microservices

Since our founding in 2013, Docker – and the ecosystem that has thrived around it – has been built around the core workflow of a Dockerfile that creates a container image that in turn becomes a running container. Docker containers, in turn, helped to drive the growth and popularity of microservices architectures by allowing independent parts of an application to be turned on and off rapidly and scaled independently and efficiently. The challenge is that as microservices adoption grows, a single application is no longer based on a handful of machines but dozens of containers that can be divided amongst different development teams. Organizations are no longer managing a few containers, but thousands of them. A new canonical object around applications is needed to help companies scale operations and provide clear working models for how multiple teams collaborate on microservices.

At the same time, organizations are seeing different configuration formats emerge including Helm charts, Kubernetes YAML and Docker Compose files. It is common for organizations to have a mix of these as technology evolves, so not only are applications becoming more segmented, they are embracing multiple configuration formats.

Docker Applications are a way to build, share and run multi-service applications across multiple configuration formats. It allows you to bundle together application descriptions, components and parameters into a single atomic unit (either a file or directory) – building in essence a “container of containers”.

  • The application description provides a manifest of the application metadata, including the name, version and a description.
  • The application component consists of one or more service configuration files and can be a mix of Docker Compose, Kubernetes YAML and Helm chart files.
  • Finally, the application parameters define the application settings and make it possible to take the same application package to different infrastructure environments WITH adjustable fields.

Docker Applications are an implementation of the Cloud-Native Application Bundle (CNAB) specification – an open source standard originally co-developed by Docker, Microsoft, Hashicorp, Bitnami, and Codefresh and with more companies onboard today.

Docker Applications in Docker Enterprise 3.0

In Docker Enterprise 3.0, we begin to lay the groundwork for Docker Applications Services. You will be able to begin testing the ‘docker app’ CLI plugin with Docker Desktop Enterprise which provides a way to define applications. These are then pushed to either Docker Hub or Docker Trusted Registry for secure collaboration and integration to the CI/CD toolchain. With the latter, you can also perform a binary-level scan of the package against the NIST CVE database. Finally, the parameterized environment variables make it easy for operators to deploy these multi-service applications to different environments, making it possible to adjust things like ports used during deployment.

With Docker Enterprise 3.0, organizations can continue to operate individual containers, but also have the ability to shift the conversation to Docker Applications to scale more effectively.

To learn more about Docker Enterprise 3.0:

This syndicated content is provided by Docker and was originally posted at https://blog.docker.com/2019/06/multi-service-applications-with-docker-enterprise-3-0/