Docker in everyday development
•
4 likes•2,060 views
This document provides an overview of Docker for developers. It discusses why Docker is useful for building applications, including portability across machines, isolating dependencies, and creating development environments that match production. Benefits of Docker like lightweight containers, a unified build process with Dockerfiles, standardized images from Docker Hub, and fast container startup times are outlined. Some cons like only working on Linux and added complexity are noted. Using Docker with Vagrant for a portable development environment is presented. Key Docker CLI commands and Docker Compose for defining multi-container apps are covered. Tips for debugging running containers are provided.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (10)
Similar to Docker in everyday development
Similar to Docker in everyday development (20)
Recently uploaded
Recently uploaded (20)
Docker in everyday development
- 1. Docker in everyday development What every dev should know.
- 2. Justyna Ilczuk, Senior Software / DevOps Engineer at Speaker A scalable backend that helps developers build complex apps with only front-end code. http://www.syncano.com/
- 4. Docker - An open platform for distributed applications for developers and sysadmins. * Powered by Linux Containers. Build, Ship and Run Any App, Anywhere
- 5. Why?
- 6. Why? Portability rocks! App works on all machines (not only on mine!)
- 7. Why? Isolate and version dependencies on both language and OS level - better than virtualenv (rvm)
- 8. Why? Build Dev Environment than resembles production environment - avoid strange bugs from dev/prod mismatch
- 10. Why? Installing dockerized services is trivial - You need a Postgres in version 9.4? Or redis, or Rabbitmq, Elastic Search? Just pull an image and start a container.
- 12. Docker pros Lightweight ● busybox - 2.433 MB ● debian - 85.01 MB ● nginx - 91.66 MB ● redis - 111.2 MB
- 13. Docker pros Unified build process Dockerfile FROM debian:latest RUN apt-get update && apt-get install tmux CMD tmux $ docker build -t my_image .
- 14. Docker pros Docker image format, portability, hub $ docker pull organization/image_name $ docker run -it organization/image_name command $ docker push me/my_image
- 17. Docker pros Fast, starting container in 0.2 s $ time docker run --rm ubuntu /bin/echo hello world hello world docker run --rm ubuntu /bin/echo hello world 0,02s user 0,01s system 9% cpu 0,271 total
- 18. Docker pros - summing up ● lightweight containers ● unified build process (Dockerfile) ● standardized images (Docker hub) ● fast, starting container in 0.2 s ● combining containers together ● distributed apps, microservices
- 19. Docker cons ● works only on GNU/Linux (needs vagrant / boot2docker) ● new tool to learn ● another layer of complexity & overhead - vagrant + Docker vs developing natively on your machine
- 20. Docker + Vagrant Containers on VMs
- 21. Docker + Vagrant ● Works everywhere ● Possible to try new tech, new OSes ○ CoreOS ○ Kubernetes ○ Mesos ○ etcd ○ Consul ● Distributed apps on your laptop
- 23. Tools ● Docker CLI ● Docker compose (aka fig) ● Good old make
- 24. Docker CLI - the most important command Running containers $ docker run --rm ubuntu echo “Hello docker” $ docker run -d -p 8080:80 nginx $ docker run -it -v `pwd`:/app -p 8000:8000 my_app
- 25. Docker CLI - checking state Checking state of containers $ docker ps $ docker images $ docker logs my_container $ docker top my_container
- 26. Docker CLI https://docs.docker. com/reference/commandline/cli/ $ docker --help $ man docker 37 commands (for everything and more)
- 28. Containers everywhere $ docker rmi $ docker rm
- 29. Time for a better tool Docker Compose
- 30. Docker Compose Compose is a tool for defining and running complex applications with Docker.
- 31. Docker Compose ● Define your containers in simple yaml file. ● Compose container together. ● Manage group of containers with single tool.
- 32. Demo of Docker Compose
- 33. Docker Compose - config docker-compose.yml redis: image: redis volumes: - /var/docker/redis:data ports: - "6379" web: build: . ports: - "80:8080" links: - redis:redis volumes: - .:/app environment: - VARIABLE=value
- 34. Docker Compose - config redis: image: redis volumes: - /var/docker/redis:data ports: - “6379”
- 35. Docker Compose - config web: build: . ports: - "8090:8080" links: - redis:redis volumes: - .:/app environment: - VARIABLE=value
- 36. Docker Compose - commands $ docker-compose build $ docker-compose up $ docker-compose ps
- 38. All is rainbows and unicorns now, right?
- 39. Compose - good for running containers But missing dependencies.
- 40. Updating images ● Developers Bob and Alice work on an App. ● They use docker-compose to run App ● Bob adds new feature that requires Dependency X to be baked into Docker image ● He updates the requirements.txt file that is used in Dockerfile and rebuilds his image
- 41. Updating images ● Cool feature is merged to trunk ● Alice pulls changes ● Alice starts docker-compose and app breaks, because of missing dependency in the container
- 42. Technical of people problem? Should Alice remember to run `docker- compose build`, `docker-compose rm` and `docker-compose up` after each pull?
- 43. Automate everything. Use smart technologies. Use Make.
- 44. Good ol’ Makefile run : build docker-compose up -d build : .built .built : requirements.txt Dockerfile docker-compose build touch .built stop : docker-compose stop clean : stop docker-compose rm rm .built test : .built docker-compose run web ./run_tests.sh ${ARGS} .PHONY : run build clean stop test
- 45. Good ol’ Makefile run : build docker-compose up -d build : .built .built : requirements.txt Dockerfile docker-compose build touch .built
- 46. Makefile ● Uses docker-compose ● Best for dependencies ● Self documenting
- 47. Other problems that you might encounter
- 48. Ups… something went wrong. Building image failed. - it stops at layer that failed - starts from the last correct layer (cache)
- 49. Ups… something went wrong. App in containers behaves in a strange way: Logs and errors - logging to stdout - logging to volumes - logging straight to Centralized Logging - logging to sentry
- 50. Ups… something went wrong. https://github.com/slafs/sentry-docker <3
- 51. Ups… something went wrong. Operating on a live patient - Debugging running containers - no need for ssh - … no need for nsenter - $ docker exec -it my_container bash