Deploying the Sock Shop Microservices Demo on Apcera
One of the most popular microservices demo applications is Sock Shop which simulates an e-commerce website. The services are written in node.js, Java, and Go and interact with MySQL, MongoDB, and RabbitMQ. The demo can be used to demonstrate the deployment, testing, and monitoring of microservices and cloud native technologies.
Two months ago, my boss, Jared, asked me to create a demo for DockerCon 2017 that would feature Sock Shop on the Apcera Platform. In particular, he wanted me to deploy all the services from a single manifest file so that the entire Sock Shop application could be started with a single command. I had actually just joined Apcera, so I still had a lot to learn both about Apcera itself and some of the technologies used by Sock Shop including Docker. I plunged into the project and have really enjoyed it.
Creating the manifest was easy using the Sock Shop docker-compose.yml file as my guide. Adding some scripts to load the manifest and start, stop, and delete all the services was also easy. But I also had to make sure the services could all talk to each other.
My first approach was to put all of them on a single Apcera virtual network. When I looked at the Docker Compose deployment, however, I found that the services were configured to refer to each other using hostnames rather than the fully qualified domain names (FQDNs) used by Apcera.
To address this, I downloaded the code for some of the services from GitHub and modified the hostnames to FQDNs. I was then able to stage the modified services from source code while deploying the other services directly from their original Docker images.
Hybrid Source Code / Docker Deployment of Sock Shop on Apcera
It occurred to me, however, that a more realistic and secure deployment on Apcera would actually use two virtual networks (internal and external), place the front-end and zipkin services outside of them, and use job links to enable communications across the network boundaries. Additionally, I added job affinity tags to make sure that the main services and their databases are always deployed together.
Apcera Virtual Networks and Job Links
I also added job labels to all the services to make them easier to find amongst the hundreds of microservices and applications that can be deployed to a single Apcera cluster. Finally, I created an Apcera policy with job scheduling tags like "vmware", "aws", and "gcp" so that the entire Sock Shop application can easily be moved from one cloud to another by editing a single line of the policy.
Here is a short video of the source code / Docker version of the demo I recorded:
After documenting the demo for the rest of the solutions consulting team at Apcera, I started thinking about enabling anyone to deploy Sock Shop on Apcera. I wanted to document this on the public Sock Shop website but knew it would be better if I could figure out a way to only use code from the master branch. So, I revisited the question of deploying all the services to Apcera from the original Docker images.
By this point, I had become more knowledgeable about the code and frameworks used by the services and realized that it was possible to use FQDNs in all but one of them by adding environment variables or start command arguments. One change was also needed in the front-end code. After filing two pull requests against the public GitHub repository, getting them approved, and doing some testing, I was able to run a pure Docker deployment of Sock Shop on Apcera. I even added the user-sim load testing service which I had left out of the hybrid demo.
Pure Docker Deployment of Sock Shop on Apcera
I'm pleased to announce that the Sock Shop on Apcera page documenting how to deploy the pure Docker version of Sock Shop on Apcera was published to the Sock Shop website last week along with the Apcera manifest, scripts and policy file. Take a look and try it out. If you're not already using Apcera, you can easily download and install the Apcera Community Edition.