Docker Containers: Developer’s experience and building robust developer environments
5 likes82 views
The document discusses the evolution of developer environments with a focus on Docker as a pivotal tool for building and managing containers. It emphasizes the importance of creating flexible and efficient development workflows, including the use of multi-stage builds and 'incubator' containers for application image building. The author advocates for embracing Docker's capabilities to enhance local development and improve team collaboration while maintaining simple setups that can easily be replicated across different machines.
Docker Containers: Developer’s experience and building robust developer environments
- 1. DOCKER CONTAINERS Developer’s experience and building robust developer environments
- 3. The Old Way Corporate Network DEV DB Version Control PROD DB Prod Tomcat Deploy Machine Test Tomcat Dev Stations New code Checkout, build Deploy Deploy
- 4. We Were Lucky It was not possible to install used database engine to a developer machine (at least it was not easy)
- 5. Years Went On... We investigated on building batteries included developer environments with stuff like VirtualBox and Vagrant
- 12. Docker is like a spacecraft Containers should be like screwdrivers
- 13. A Container is an abstraction of Unit of Work
- 14. Mixing Building and Running in the Same Container This is a really common pattern, also in production systems It produces a Docker image that is more like a spacecraft than a screwdriver CMD is just a default for Docker run command So one can easily run something like: docker run -it acme-api npm login
- 15. Multi Stage Builds is a Bliss I think this is the most important new feature in Docker, because this is something that was really complex to achieve before. Unfortunately all official node alpine images include NPM. There is a Github issue on this: https://github.com/nodejs/docker-node/issues/404 But now your image starts to look more like a screwdriver!
- 16. But what you can and should do.. … is to create ”incubator” containers that exist just for built just for building you app image The best situation would be that one is able to run incubator locally
- 17. Avoid Building Hard Environmented Images docker run acme-api-production:1.2.3 docker run acme-api-development:1.2.3 docker run acme-api-local:1.2.3
- 18. Build Flexible Images docker run -e "DB_HOST=localhost" -e "DB_USER=foobar" –e "DB_PASS=notsecret" acme-api:1.2.3 docker run -e "DB_HOST=db.acme.org" -e "DB_USER=acme_db" –e "DB_PASS=crypto-store:/acme-api/db-password" acme-api:1.2.3 Make tooling! (run-acme-api-locally.sh) Sensible local defaults! Devs need to be able to easily launch same containers locally! TRUST THE ENV LUKE!
- 19. I want To Hot-Reload Code From My IDE to a Running Container Locally!? Don’t EVER support this in the image that is meant to be deployed to a live environment Instead, make tooling for building local images that support hot reloading docker run acme-api-hotreload:localbuild (Disclaimer: I don’t know, if this is actually a good idea in the first place…)
- 20. Give team the possibility to embrace Docker and Containers
- 21. We should talk more about Development Architecture Running in production is a one thing Developing is something that has not been addressed that much
- 22. Works on my machine We must avoid magic machines Your repository should always be runnable in a new machine ”in fifteen minutes”
- 23. If you have a good workflow Share it, if possible Current blogsphere on (cloud) development architectures is somewhat non-existent
- 24. Embrace DevOps Culture Do not hide containers Embrace and enable developers to test and run stuff locally in containers as well