containers for applications ▸ Runs its own libraries and programs on host kernel ▸ Uses resource isolation and namespaces to secure host ▸ Docker and Containers are commonly used synonymously @davejlong
▸ Similar setup as production ▸ Easy startup and shutdown ▸ Easily on-board new developers ▸ Self-documenting system changes Containers In Production ▸ Isolation of applications ▸ Better security* ▸ Smaller than traditional VMs ▸ Easy to remediate issues ▸ Easy to scale @davejlong
and is not interactive ▸ docker-compose run {service} instead ▸ Sometimes things don’t start the first time you try ▸ Postgres is a big culprit ▸ When possible use Alpine images ▸ They’re much smaller and so pull much faster ▸ Version in compose file must be a string @davejlong
as root… mostly ▸ Kernel capabilities means “container root” != “host root” ▸ OpenSSL in a container is still OpenSSL ▸ Docker doesn’t do magic ▸ Outdated packages in containers are still bad ▸ If your app can talk to the database, so can a hacker ▸ Follow best practices for securing any server ▸ Security by destruction @davejlong
dies, so does it’s data ▸ If you need it, don’t keep it in a container ▸ Can it be built into the container? ▸ Rails assets ▸ Storage must be available across cluster @davejlong
container dies, so does it’s data ▸ Setup logging system ▸ ELK ▸ Loggly ▸ Logentries ▸ Pick a monitoring system that can monitor containers ▸ New Relic ▸ Dynatrace @davejlong