Successfully reported this slideshow.

Containerize everything - Wildcardconf 2015

3

Share

Loading in …3
×
1 of 52
1 of 52

Containerize everything - Wildcardconf 2015

3

Share

Download to read offline

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

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

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Containerize everything - Wildcardconf 2015

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