Containerize everything - Wildcardconf 2015

1. Containerize Everything!
2. @oscarrenalias github.com/oscarrenalias oscar.renalias@accenture.com oscar@renalias.net www.linkedin.com/oscarrenalias www.slideshare.net/oscarrenalias
3. This is going to be opinionated
4. Old-fashioned clients can run containers too!
5. Architecture nginx Tomcat TomcatTomcatTomcat PostgreSQL Solr
6. Architecture services Rundeck Yum repo & mirror Reverse proxy Docker Registry
7. Why containerize everything?
8. Simplified packaging, deployment and execution
9. Flexibly provision components on inflexible infrastructure
10. Better resource utilization
11. Anyone can have a production-like environment on their local workstation…
12. …or any other server
13. Our container principles
14. One single logical service per container
15. Containers are cattle, not pets
16. No SSH in containers
17. Try not to persist state in the container
18. Containers are independent (and unaware!) of where they’re running
19. Host port forwarding for network communication
20. How?
21. Container hierarchies base java tomcat service nginx postgres centos:6 frontend database Infra 1 Infra N
22. Building containers
23. Building containers automatically Publish artifacts Integration Test Build & unit test
24. Testing containers Container under test Test container: • Ruby • ServersSpec • ServerSpec Tests FROM …
25. Testing containers Container under test Test container
26. Storing containers Registry 2.0
27. Deploying and running containers Registry Container host Build & Publish Pull docker run
28. supervisor is your friend, if you need it
29. Application and container configuration Application container confd
30. Host Application and container configuration Application (container) Application configuration
31. Security
32. Run containers with their own user USER <user>
33. Keeping containers up-to- date base java tomcat service nginx postgres centos:6 frontend database Infra 1 Infra N OpenSSL Bug! base java tomcat service nginx postgres frontend database Infra 1 Infra N
34. Be mindful of SELinux
35. Operating containers
36. Container state Real world: don’t keep it in the container if you can avoid it Ideal world: containers don’t have state vs
37. Logging • Write to host (and use external aggregator) • Log to standard output (< 1.6) • Standard output + syslog logging driver (>= 1.6)
38. Monitoring Container processes are just like any other process and service – use existing tools
39. The darker side of Docke
40. Immutable containers are fun… until there’s an urgent security update
41. Docker will keep evolving
42. Sooner or later you will be bitten by a weird interaction between Docker or kernel or PAM or SElinux/AppArmor, and a container
43. No version pinning in the registry: “centos:6, is that you? You looked different yesterday!”
44. Docker security needs attention from implementers https://benchmarks.cisecurity.org/downloads/show-single/index.cfm?file=docker16.100
45. Our lessons learned
46. Docker as a container engine *is* ready for production workloads
47. Docker works well as a convenient way of packaging, deploying and running applications
48. Containerizing everything does give you more flexibility…
49. …but be pragmatic
50. Dockerfiles are all you could possibly need to build containers
51. Start small – containerizing everything is a fair goal but takes time

Editor's Notes

We won’t cover the basics.
Docker has dramatically changed the way we package, deploy and run applications.
Millions of downloads of the engine, hundreds of millions of images from registry. Absolutely impressive for a 2 year old project.

This is going to be opinionated.

In a real project, for a very classic client.

How many of you are you still working in a scenario where releases are deployed to production by giving a .zip package and a word file with instructions to a third party, for installation?

We don’t have the luxury of working on cloud, yet, so containers are for us a much more granular way of deploying content as opposed to deployment to Tomcat. Containers let us for example easily deploy multiple releases of the same application more than once to the same server, without the need to deal with kludges.

This is a way for us to segregate the functionalities of containers; if there's a function that does not seem to belong to a container, then it gets spun off to its own container.

This does not necessarily mean that one container runs a single process!

Use docker exec.

We don't really like data volumes and data-only containers.

Container hierarchies are necessary so that we can segregate responsibilities between containers; the smaller and the less they do, the better.

They also help to keep build times shorter, e.g. creating a container by simply coping a WAR file into it is way faster than building it every time from scratch.

The hard part: changing one of the containers at the very top means that we need to rebuild every single container. For minor changes this is not a problem since we can roll out updated containers at our own pace but for critical updates such as security fixes, it may be a bit problematic.

Existing previous investment in Puppet for automation, which is still currently used.

However, containers are being slowly migrated to plain Dockerfiles.

We started with Artifactory as it’s our über-repository for all sorts of artifacts. With Docker 1.6, we decided to move to Docker registry 2.0.

While Jenkins builds containers, Rundeck is responsible for deploying them to hosts.

Integration between Jenkins and Rundeck has not been implemented yet, but it’s in the plans.

Remember the restart policies!

Use USER in Dockerfile, or –u with docker run

Don’t keep it in the container:
Data volumes (though I don’t like them), or data-only containers
Write to host if you have to
Or do not containerize applications with tons of state (e.g. databases)
Put state in a networked filesystem

The darker side of Docker.

- Can’t sign containers
- Logging API was very much needed – and it was only just finished

Tags can be overwritten in a registry without anyone realizing. For example, it’s hard to say if today’s centos:6 is the same as yesterday when you make a new build. Solution: build your own, or keep a local copy.

Docker is ready for production workloads; your expected level of integration and automation will define how much infrastructure “glue” you need to design and build on top – e.g. service discovery, automation, load balancing, etc.

Containerize everything - Wildcardconf 2015

You are reading a preview.

Containerize everything - Wildcardconf 2015

More Related Content

Similar to Containerize everything - Wildcardconf 2015

More from Oscar Renalias

Featured

Related Books

Related Audiobooks