-
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
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.