Eye acorn of a Docker Compose user

In the last article of our series on the Acorn Platform as a Service for Kubernetes, I introduced the architecture and design of the Acorn deployment framework. This tutorial will compare Acorn with Docker Compose and Kubernetes object definitions.

Before going any further, make sure you have followed the steps for installing Acorn on Minikube explained in the previous tutorial.

Step 1: Explore the Azure Vote Microservices application

Let’s choose a simple containerized application popular among Docker developers: the Azure Vote application.

The application consists of two layers – a Python Flask interface and a Redis backend. Each layer of this microservices application is deployed as a container.

To explore the deployment artifact, clone it GitHub repository and open the file azure-vote-all-in-one-redis.yaml

The directory includes all assets including the Docker Compose file and source code.

│ azure-vote-all-in-one-redis.yaml
│ docker-compose.yaml

│ │ app_init.supervisord.conf
│ │ Dockerfile
│ │ Dockerfile-for-app-service
│ │ sshd_config
│ │
│ └───azure-vote
│ │ config_file.cfg
│ │ main.py
│ │
│ ├───static
│ │ default.css
│ │
│ └───templates
│ index.html


Launch the app with Docker Compose and navigate to the web app.

Now that we have a working Docker Compose application, let’s map the concepts to Acorn.

Step 2: Porting the Azure Vote app to Acorn

Technically speaking, we don’t need to port the app. Since the building blocks of Docker Compose, Acorn, and Kubernetes are container images, we’ll focus on mapping the definition to Acorn.

Open the Docker Compose file and examine the service definition.

Lines number 3-9 define the Redis service by pulling the image, setting the environment variable to enable a blank password, and exposing the port. The remaining lines create the container image from the Dockerfile residing in the azure-vote directory, by connecting the web application to the Redis backend and expose it on port 8080.

Now let’s create the Acorn definition for the same application. Create a directory called Acorn, which contains the Acorn file.

Run the application with the command below:

Get the application URL by running acorn apps ordered.

Access minikube IP after change host header shows the Azure Vote app in the browser.

It is obvious that Acornfile is similar to Docker Compose file.

The definitions and structure are similar except for the deployment target. Docker Compose runs in the context of Docker Engine, while Acorn targets a Kubernetes cluster.

Feel free to compare and contrast the Kubernetes YAML file with Acornfile. Acorn simplifies the definition of multi-container workloads while translating it into respective Kubernetes objects.

You can see how Acorn translates the definition into Kubernetes objects when you explore the namespace created for the Acorn application.

Step 3: Link resources with Acorn

PaaS implementations such as Cloud Foundry support binding stateful resources such as databases and cache with one or more stateless services. This approach makes it possible to reuse services without recreating them or managing complex synchronization between resources.

Acorn brings binding to Kubernetes applications with a simplified approach. It mimics Cloud Foundry by linking existing services. In the Acornfile app for Azure Vote, we have a Redis service that we can bind to a service deployed in another app.

To explore this concept, create a new directory and an Acornfile with the contents below:

This file creates an Acorn application with a single microservice based on the Redis image. The idea is to leverage the Redis client CLI in this application to access the Redis server running in the Azure Vote application.

Launch the application with the command below:

Notice the switch --link which connects the current application (redis client) to the azure-vote-back service belonging to the silent-sun Acorn application.

Access the container with the acorn exec ordered.

Let’s connect to the Redis host to access the key/value data stored by the Azure Vote application.

We are now able to reuse a Redis backend for multiple clients. Interestingly, the Redis client can connect to the server with the hostname mentioned in Azure Vote Acornfile.

Behind the scenes, Acorn created a service with the redis-client application namespace. The particularity of this service is that it is of type ExternalName. According to Kubernetes Documentation, an ExternalName Service is a special case of a Service that has no selectors and uses DNS names instead. In this case, the azure-vote-back DNS name simply points to the service residing in the Azure Vote application namespace, silent-sun.

Using the ExternalName service to bind services between applications is a smart way to leverage Kubernetes primitives to mimic PaaS functionality.

In the next part of this series, we’ll explore the workflow involved in iterating code through development environments and moving Acorn applications to a production environment. Stay tuned.

Band Created with Sketch.

Comments are closed.