Docker has taken the IT industry by storm, and undeniably it is one of the most popular technologies these days. Docker is being adopted widely because of its simplicity to develop, test and deploy. It is loved by DevOps community as it is inherently designed to build once and deploy in different environment multiple times. The docker containers are ideal deployment units in Microservice Architecture (MSA) because it is very easy to spin new containers and scale them up and down as per the need. Though Docker has such a widespread adoption and it solves many industrial use cases, there are many containerization anti-patterns emerging due to the misunderstanding of containerization. In this talk we will explore: some of the anti-patterns, symptoms to identify those anti-patterns and the solution.

1. Containers: Anti-patterns
Jeeva S. Chelladhurai
sjeeva@gmail.com
https://www.linkedin.com/in/jeevachelladhurai

2. Why containers

3. Structure
• Synopsis
• Symptoms
• Prognosis
• Side effects
• Cure
• Exceptions

4. VictiMizing
• Synopsis:
• Converting a container as a VM (VMizing)
• Symptoms:
• Linux, RHEL, CentOS, Fedora, Ubuntu
• SSH/Telnet Connection, SCP/FTP Transfer
• Cron Job
• Prognosis:
• Marring to the old habits
• Purpose of containerization is not understood
• Side effects:
• Bloated image size
• Increased attack surface
• Cure:
• Narrow it down to application runtime

5. Overloading
• Synopsis:
• Running multiple services inside a container
• Symptoms:
• Running upstart or systemd
• Prognosis:
• Purpose of containerization is not well understood
• Side effects:
• Cannot DevOps or scale individual services
• Cure:
• Separation area of concern: Run one application inside the container in the foreground
and connect to the dependent service like any other backing service
• Exceptions:
• Zombie reaper like tini (--init)
• Tight dependency between services (really?, I still feel it can be separated)

6. Skidding
• Synopsis:
• Dockerfile FROM instruction with a moving tag
• Symptoms:
• Under qualified or non-concrete image in the Dockerfile FROM instruction
• FROM python:3 or FROM python:latest
• Prognosis:
• Quick hacking mode
• Impact of version change and immutability is not well understood
• Side effects:
• Unexpected failures during image rebuilds
• Cure:
• Always fully qualify the image name with tag or digest (later is recommended)
• FROM python:3.6.3-alpine3.6
• FROM python@sha256:b29985dc837ae19408a89cdd6c72653e3aeed9cc731a3be81472f035f9d16f60

7. Petting or Tinkering
• Synopsis:
• Working inside a container
• Symptoms:
• The workflow involves exec-ing or attach-ing to the container
• Prognosis:
• Quick hacking mode
• Either immutability is not understood or ignored
• Side effects:
• Cannot be automated or involves tools like expect
• Cure:
• Dockerfile with ENTRYPOINT and/or CMD

8. Desensitizing
• Synopsis:
• Storing sensitive information in the image file system
• Symptoms:
• Applications using sensitive information like password and tokens from the container file
system
• Prognosis:
• Gap in understanding the docker image filesystem and related commands
• Side effects:
• Sensitive information can be retrieved from the image file system
• Cure:
• Pass sensitive information to the container thru env variable or mounted files

9. Fleeting
• Synopsis:
• Storing application state and logs in the containers ephemeral filesystem
• Symptoms:
• No strategy around storing and handling container’s state and logs
• Prognosis:
• Either immutability is not understood or ignored
• Side effects:
• Losing the state of containerized application and logs
• Cure:
• Use volumes or external data store to persist the container state
• Route container logs to external log handlers like graylog, syslog and etc

10. Thanks
Jeeva S. Chelladhurai
sjeeva@gmail.com
https://www.linkedin.com/in/jeevachelladhurai
https://www.meetup.com/preview/opensourceblr
https://www.meetup.com/preview/jenkinsBLR
https://www.meetup.com/preview/EthereumBlr

11. Open Source Meetup Jenkins Area Meetup Ethereum Meetup