Docker mistakes
Docker mistakes so you don't have to.
@MrDanack
Press 'c' to toggle code style Press 's' for speaker notes
Developer time is expensive
Some of the mistakes were as simple as "we need to talk about how to implement this"
e.g. which files should we copy the files into the container. If we just copied all files
then the container would have been 5MB bigger, but saved three hours of developer time.
So some of these don't apply if you are deploying 1000 instances of a container.
Not using docker already.
Even if you're not going to use containers for deployment, docker is really good for switching between branches.
My last job, doing a vagrant up took about 30 minutes, so if someone asked if I could debug something on a different branch, the answer was going to be no most of the time.
Docker too slow for yarn/webpack on OSX
I'm a strong believer that all of the tools someone needs should be usable after a single clone of a repo.
So we tried to make webpack work within a container.
Spent quite a bit of time setting this up. Didn't work well on OSX the file system is just too slow, and how many frontend developer use linux?
Just install npm/yarn through Brew - works fine.
Forget Docker networking
Setup loopback address on host machine
Available both from the host and the docker boxes.
com.ralphschindler.docker_10254_alias.plist
https://gist.github.com/ralphschindler/535dc5916ccbd06f53c1b0ee5a868c93
Setup loopback address means same IP used anywhere.
Makes it so you can test code outside of the container.
Not setting WORKDIR
WORKDIR /var/www
Puts you in the correct directory when you bash into the box.
Dependencies between containers
We thought we were being clever by having a 'common' php box image, and then adding stuff.
Added so much complexity - doing `docker-compose up --build' could fail.
Just copied the bits to be separate. And then edit them both.
Except xdebug enabled
Makes debugging code in server be as simple as adding :8001
Docker file
FROM php_backend:latest
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y \
--no-install-recommends php7.2-xdebug
COPY xdebug.ini /etc/php/7.2/fpm/conf.d/20-xdebug.ini
Docker file for extending php box.
xdebug.inizend_extension=xdebug.so
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.remote_autostart=1
; Remote connect back doesn't work in docker
; as the incoming request IP doesn't map back
; to the host properly.
xdebug.remote_connect_back=0
; Loopback ftw
xdebug.remote_host=10.254.254.254
One process per container
Boo!! I SAY BOOOOOOO!!!!!
Typical deployment is LoadBalancer with lots of nginx backends
LB knows about domain names + pools. Backends know about their application e.g. aware of files
Complete duplication of files if separated, and can't use sendfile.
Harder to configure as nginx backend needs name of php backend.
Script Two things at the same time
Better: one deployable unit per container
Make containers be logical units rather than things that can't be deployed.
Domain names like
local.api.foobar.com
Not
api.local.foobar.com
Allows you to setup wildcard domain names, rather than hand-craft them.
Setup domain names once at the routing load-balancer.
*.example.org
Also Google chrome gets confused when you have the environment in the middle.
Config files belong in repo for containers
We separated them out to be built by helm when the container gets built. Our helm stuff is in a separate repo.....which means that even to just find out what a container is using in prod means searching around.
Put them all in the container and choose from an environment flag passed in
Or build them on the fly each time if you're cool enough.
Really all files in source control - none taken from /etc
/usr/sbin/php-fpm7.2 \
--fpm-config=/var/www/docker/php_backend/config/php/fpm.conf \
--daemonize \
-c /var/www/docker/php_backend/config/php.ini
Leave them where they are in your repo.
Don't refer to files that ship by default, put them all under source control.
Avoid inheritance - copying and pasting from one container to another is fast.
Supervisord is still rather awesome.
Both Docker and Kubernetes are reinventing the wheel for this tool.
Allows pure devs to setup running tasks
Allows dev environment to match live environment unlike kubernetes cron jobs.
Easier to allocate resources...
Copy all project files into container
├── src
├── public
├── docker
│ └── php_backend
│ └── Dockerfile
├── docker-compose.yml
volumes:
- .:/var/www
docker build -t load_balancer:latest \
--file ./docker/php_backend/Dockerfile .
Makes life so much simpler.
By default not possible as docker will only include files from under the docker file location.
Use 'build context' to make it include all from project root - except stuff you don't want e.g. node_modules in docker ignore.
