Containerize everything - Wildcardconf 2015
•Télécharger en tant que PPTX, PDF•
3 j'aime•1,438 vues
Docker is definitely one of the hottest technologies at the moment and one that is already dramatically changing the way we build, package and deploy applications. In this session we’ll have a look at how a project got into a quest for containerizing most of their components and services while increasing the value delivered. This presentation was delivered at Wildcard Conference 2015, on 16th of May 2015 in Riga
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Containerize everything - Wildcardconf 2015
Similaire à Containerize everything - Wildcardconf 2015 (20)
Plus de Oscar Renalias
Plus de Oscar Renalias (9)
Dernier
Dernier (20)
Containerize everything - Wildcardconf 2015
- 4. This is going to be opinionated
- 5. Old-fashioned clients can run containers too!
- 7. Architecture services Rundeck Yum repo & mirror Reverse proxy Docker Registry
- 9. Simplified packaging, deployment and execution
- 10. Flexibly provision components on inflexible infrastructure
- 12. Anyone can have a production-like environment on their local workstation…
- 13. …or any other server
- 15. One single logical service per container
- 16. Containers are cattle, not pets
- 17. No SSH in containers
- 18. Try not to persist state in the container
- 19. Containers are independent (and unaware!) of where they’re running
- 20. Host port forwarding for network communication
- 21. How?
- 22. Container hierarchies base java tomcat service nginx postgres centos:6 frontend database Infra 1 Infra N
- 24. Building containers automatically Publish artifacts Integration Test Build & unit test
- 25. Testing containers Container under test Test container: • Ruby • ServersSpec • ServerSpec Tests FROM …
- 26. Testing containers Container under test Test container
- 28. Deploying and running containers Registry Container host Build & Publish Pull docker run
- 29. supervisor is your friend, if you need it
- 30. Application and container configuration Application container confd
- 32. Security
- 33. Run containers with their own user USER <user>
- 34. 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
- 35. Be mindful of SELinux
- 37. Container state Real world: don’t keep it in the container if you can avoid it Ideal world: containers don’t have state vs
- 38. Logging • Write to host (and use external aggregator) • Log to standard output (< 1.6) • Standard output + syslog logging driver (>= 1.6)
- 39. Monitoring Container processes are just like any other process and service – use existing tools
- 40. The darker side of Docke
- 41. Immutable containers are fun… until there’s an urgent security update
- 42. Docker will keep evolving
- 43. Sooner or later you will be bitten by a weird interaction between Docker or kernel or PAM or SElinux/AppArmor, and a container
- 44. No version pinning in the registry: “centos:6, is that you? You looked different yesterday!”
- 45. Docker security needs attention from implementers https://benchmarks.cisecurity.org/downloads/show-single/index.cfm?file=docker16.100
- 47. Docker as a container engine *is* ready for production workloads
- 48. Docker works well as a convenient way of packaging, deploying and running applications
- 49. Containerizing everything does give you more flexibility…
- 51. Dockerfiles are all you could possibly need to build containers
- 52. Start small – containerizing everything is a fair goal but takes time
Notes de l'éditeur
- 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.