Everybody in our team knows how to create stable and scalable software products. But in this case, we are using Docker... and it really helps us to concentrate on development and spend more time on code review & tests instead of troubleshooting issues with servers.

1. Launching <new application> fast
scala & docker ✈ production

2. whoami
Denis Karpenko
denis@karpenko.me
linkedin.com/in/dkarpenko/en

3. What is this talk about
● Sharing approach of delivering our application
○ Benefits
○ Motivation
○ Compromises in architecture
● Willing to hear your opinion on topics discussed

4. 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

5. Application

6. 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)

7. 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

8. Build process: SBT buildfile
val 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

9. 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.

10. Infrastructure

11. 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)

12. 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?

13. 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

14. Logging
● Didn’t want to “invent” configuration for each
server component (DB, applications,...)
● And were happy to find generic approach

15. 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

16. Logging: FluentD as a container
● http://www.fluentd.org/guides/recipes/docker-logging
● https://github.com/ChristianKniep/docker-elk

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

18. 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

19. 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

20. 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

21. Remote API for deployment (maybe)
● https://docs.docker.com/reference/api/docker_remote_api/

22. 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

23. post scriptum

24. Trends: ansible & docker

25. Trends: ansible, docker, j.bieber

26. Trends: recommendations
● Read less marketing materials
● Take only what you need for solving current
problem
● Plan B: keep it in mind

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

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

29. Q & A