This blog post is a brief summary of our webinar hosted together with Codefresh on Thursday 9th February 2017. Webinar includes two talks: "Docker Inside/Out: the ‘real’ real-world of stacking containers in production" (the 12 stages) by Daniel van Gils and "Testing Strategies for Docker Driven Development" (the 4 scenarios) by Alexei Ledenev.
If you missed the webinar, click on the image below to find out more about the tips and tricks to run Docker containers in production and review the testing strategies for your deployments.
The webinar covered the following points:
- Introduction to Codefresh and Cloud 66;
- Daniël van Gils talks about "Docker Inside/Out: the ‘real’ real-world of stacking containers in production". This includes 12 stages of the hero journey to run containers in production as well as the examples of how developers really use microservices.
- Alexei Ledenev talks about "Testing Strategies for Docker Driven Development". It shows a step-by-step demo for testing scenarios to achieve the ultimate solution.
An excellent progression showcase with the benefits and drawbacks for each scenario.
Talk no. 1: Summary
The 12 stages of the Hero journey to containers in production.
First couple stages are very straight forward, you work on your project with the methods that you already know. Then you hear about "containers" at the conference, meetup, blog or hear from your colleague. You see what they can do and it looks magical! :)
Next, at stage three you start to think, How can I implement containers in my current workflow. You conduct some research to get the idea. But you need practical knowledge and experience to use containers in production.
Stage four: Meet Your Mentor! Mentor is someone who's already using containers in production and knows more than you, and is happy to take you on the containers journey, for example, Daniël :)
Apply the artichoke model , which shows each role in your company can benefit from containers. Meaning, everybody needs to understand the core concepts of containers and their impact on the organization. It's part of change management.
Stage five: Now you are crossing the threshold and start to understand the containerization machine. Try using containers with the simple project, and move to more difficult ones. This will involve a lot of testing (more about testing from Alexei's talk).
\ *Golden rule: Make sure that containers work on your local machine, before moving to production! Think global, act local.
Stage six: You are using the containers, run into some problems and have made some mistakes. This is part of the process. Try to take a step back and take your time to find a solution, No shortcuts. This is the stage where most of the developers realize that their Docker image contains too many components and half of them are not needed. Try to clean your image.
Remember "sh#t in and sh#t out", you can't polish a turd.
Welcome to stage seven. Now you are more aware of what your container image needs. And you need to *Keep It Slim, Secure, Speedy, Stable, Set! K.I.S.S.S.S.S.
- Slim , remove all the layers that you don’t need;
- Secure , ensure you have the latest updates and remember to remove all secrets;
- Speedy , follow best deployment practices and run performance tests;
- Stable , use version numbers for your Docker files;
- Set , immutable, don’t put databases or complicated volumes into your containers. You can, but the the technology is still too new.
Stage eight. It's time for PRODUCTION! Tah da! But first, let's do the reality check.
Does everybody really use the microservices? The answer is: No.
- 60% of developers use a monolith containerisation. This is understandable as it is a part of the learning curve.
- 30% of developers use an API first approach, mainly when dealing with the frontend.
- 7% of developers split their architecture with the containers. This includes workers, API and background processes etc.
- and only 3% of developers are truly using the microservices in their projects.
Stage nine. Now you know all the parts of the containers ecosystem and what you need to look after. This is your container nursery :
Stage ten. Proof of concept - done. You know how to implement the containers and now you need some head space, check what services, products are out there, and observe the market for new technologies.
Stage eleven. With the knowledge and the experience you gained, you have a new approach and you understand what you need to fit containers in your infrastructure.
Stage twelve. You are a containers hero. You and anybody who joined your journey understand the power of containers and how it can be applied to all the projects and divisions.
Talk no. two: Summary
Testing Strategies - how to create a test lifecycle around containers.
Alexei started with listing some of the benefits of using containers, such as portability, speed, configurations, flexibility etc. with a brief description of the Docker architecture components.
Before we move to the test scenarios, these are the components for the demo app and tests:
- Demo app: all the tests are based on the simple Rest API server that is written in Golang.
- Postman - which is the Rest API testing tool with the chrome browser extension.
- Newman - reads the test scenario fails created by Postman
- Node.js application
Scenario no.1: Involves modification of the existing pipeline. AKA - naive approach :)
See the 1st scenario demo - 29 minutes 30 seconds of the webinar
The outcomes: you'll achieve a familiar CI flow, app portability, smaller Docker image but won't have a portable Dev or Test environment.
This means it isn't possible to reproduce the same development or testing environment outside the CI. The same procedure would have to be repeated for each machine.
Scenario no. 2: How we can improve the situation?
Place all the Cl flow (compile and test) in the container.
See the 2nd scenario demo - 33 minutes 38 seconds of the webinar
As a result, you'll gain the simple CI flow, application portability and portable Dev and Test environment. On the downside, the docker image gets bigger and polluted with some unneeded dependency packages. The image has to be rebuilt each time on the code or test changes and you need to decide on how to manage tests results.
Scenario no. 3: Split the image into tow.
In this test scenario, you still have one docker file with the application and test code. But you need to extract some of the image layers and split it into two images.
See the 3rd scenario demo - 38 minutes 31 seconds of the webinar
Now, the application has portability, portable Dev and Test environment, you end up with two separate images and one dockerfile. But you still need to rebuild the whole docker image on code or test changes. Also, you need some shell "magic" to create a clean app image.
Scenario no. 4: Create a Docker Automation Flow by using containers for every step, including building container, test and app container.
See the 4th scenario demo - 42 minutes 56 seconds of the webinar
You'll achieve an application portability, portable Dev and Test environment (build and test anywhere), small app image and fast build. But you'll still need a tool to automate and orchestrate Docker build flow, such as bash, ansible, dobi, Habitus.oi or Docker CI/CD services like codefresh.io or cloud66.com.