Launching <new application> fastscala & docker ✈ production

whoami

Denis Karpenkodenis@karpenko.me

linkedin.com/in/dkarpenko/en

What is this talk about

● Sharing approach of delivering our application○ Benefits○ Motivation○ Compromises in architecture

● Willing to hear your opinion on topics discussed

Development constraints

● limited in time● lot’s of moving parts (integrations) with 3rd

party systems● 100% of requests are synchronous● no dedicated devops/it specialists● (very) active development phase

Application

Application

● 2 backend applications (spray endpoints)○ not microservices

● 2 frontend application (SPA)● 6 integrations with external systems:

○ XML/JSON/Plaintext over HTTP● it’s not about highload/bigdata/…

○ N+1 instances (0?+1)

Build process

● Everything is built only once after git push● Scala applications

○ to container with sbt-native-packager● Backbone-Marionette SPA

○ to container with gulp● All configs are outside of the app

● http://www.scala-sbt.org/sbt-native-packager/formats/docker.html● https://www.npmjs.com/package/gulp-docker

Build process: SBT buildfileval dockerSettings = Seq( maintainer in Docker := "Team <dev.team@company.com>", dockerRepository in Docker := Some("private.registry.com/project"), dockerBaseImage in Docker := "dockerfile/java:oracle-java7", dockerExposedPorts in Docker := Seq(11001, 12001), dockerUpdateLatest := true)

…$ sbt docker:publish

Development & QA environments

● dev-init.sh setups envinronment in 10mins● moving to test-only containers

http://www.fig.sh/https://docs.docker.com/compose/

web:

build: .

links:

- db

ports:

- "8000:8000"

db:

image: postgres

1.$ docker-compose up

2.

Infrastructure

Server instances: limitations

It’s hard to automate instances bootstrap due to ● required manual steps● virtualization infrastructure in the company

is changing (3 virt. systems)

Server instances

We simplified server setup as much as possible● so what for do you need to ssh to server if there is nothing

to change manually?

Server instances

● reduced components installed on the server○ to minimize the risk errors○ server provisioning as simple as

■ adding authorized_keys ■ installing doker.io (yes, for now it’s not CoreOS)

○ devops project is less than 100 LOC● everything is configured outside of the server

Logging

● Didn’t want to “invent” configuration for each server component (DB, applications,...)

● And were happy to find generic approach

Logging dockerized containers

● Container provides unified interface for logs○ stdout & stderr

● Search log messages by tags○ container name or image name

● Collecting logs much simpler when using ELK or FluentD as containers

● http://www.fluentd.org/guides/recipes/docker-logging● https://github.com/ChristianKniep/docker-elk

Logging: FluentD as a container

● http://www.fluentd.org/guides/recipes/docker-logging● https://github.com/ChristianKniep/docker-elk

Metrics

● The same approach as with logging○ unified way of collecting containers’ metrics

Metrics: Datadog

● Host○ CPU, memory, I/O, ...

● Container○ resources by tag/group

● Application/business○ yammer metrics

● https://www.datadoghq.com/2014/06/docker-ize-datadog/● https://www.datadoghq.com/2014/06/monitor-docker-datadog/● https://github.com/DataDog/docker-dd-agent

Access containers via docker.sock

● Jenkins container builds other containers● Other examples

○ jwilder/nginx-proxy

$ docker run -d -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock jwilder/nginx-proxy

$ docker run -e VIRTUAL_HOST=foo.bar.com ...

● https://github.com/jwilder/nginx-proxy

Deployment● Private Docker Registry

○ to reduce external traffic (it’s always slower)○ to keep private stuff private

● Ansible ○ it’s very simple tool○ new developers becomes productive in a couple of hours○ it takes our “The best osp tool for engineers” award

● Less than 2 seconds to start container● http://thenewstack.io/are-docker-users-migrating-to-

ansible-and-away-from-puppet-and-chef/● http://www.ansible.com/docker

Remote API for deployment (maybe)

● https://docs.docker.com/reference/api/docker_remote_api/

Next steps

● Increase developers productivity● Multi-host deployments

○ service discovery & orchestration● Advanced configuration management● Deployment pipeline

○ with integration tests phases● Data management (replication)● Splitting apps into more granular components

post scriptum

Trends: ansible & docker

Trends: ansible, docker, j.bieber

Trends: recommendations

● Read less marketing materials● Take only what you need for solving current

problem● Plan B: keep it in mind

Disclaimer● We are heading to production with this setup.● We are aware of the majority all issues we

can face with.

Let’s talk about..● How your app looked like 1..2..5 years ago?● Is there anything you would change in our

setup?

Q & A