KEMBAR78
Docker based Architecture by Denys Serdiuk | PPTX
Docker based architecture
About Me
7+ years as backend Software Engineer.
● Java/Scala
● SQL/NoSQL databases
● distributed caches, queuing
● Hadoop/Spark
● AWS,DevOps
● REST, microservices
An approach to developing a single application as
a suite of small services, each running in its
own process and communicating with
lightweight mechanisms
http://martinfowler.com/
Microservice architecture style
• Component decomposition
• Independant development lifecycle and
technology freedom
• Better extensibility
• Fault isolation
Microservice benefits
• Deployment of much greater number of
services and components
• Monitoring of many services for performance
or issues
• Looking into log files from many micro-services
• Versioning between services and environment
consistency
Microservice drawbacks
1. Multiple Service instances per host
● conflicting resource requirements(CPU, memory, IO, etc.)
● conflicting dependency versions
1. Single Service instance per host
● potentially less efficient resource utilization
● hosts provisioning and maintenance
1. Service Instance per VM
● building a VM image is slow and time consuming
1. Service instance per container
● The infrastructure for deploying containers is not as rich as
the infrastructure for deploying virtual machines
Microservice deployment patterns
Containerization vs Virtualization
Containerization providers
Implementations:
● by vendors(Open Source,HP, IBM, Microsoft)
● by OS (Linux, FreeBSD, Solaris, Windows)
http://en.wikipedia.org/wiki/Operating-system-level_virtualization#Implementations.
Docker has become the most popular nowadays.
Docker Ecosystem
How it works
http://en.wikipedia.org/wiki/Docker_(software)
Docker registry
Docker container overhead
Docker container network overhead
Basic docker usage scenario
1. create Dockerfile
2. build image with specific name in format
[registry_url/]repository:imageTag , e.g
myhost:5000/mycompany/myservice:version1
1. push image into registry (private or Docker Hub)
2. pull image by repository and tag (Optional)
3. run container from image
Dockerfile
• inherit existing images
• add/copy files to container
• set environment vars
• run shell command
• expose ports
• set working dir
• share host FS with container
• --no-cache option
• CMD and bootstrapping
• CMD vs ENTRYPOINT
FROM mycompany/app-base:latest
RUN mkdir -p /opt/app
ADD core.jar /opt/app/core.jar
RUN curl http://3rd-paty.repo.org/download/component.zip && 
unzip component.zip -d /opt/app/ && rm -f component.zip
COPY lib/ /opt/app/lib
ADD bootstrap.sh /etc/mysevice/
RUN chmod +x /etc/mysevice/bootstrap.sh
ADD workspace-manager-core.jar
ADD logback.xml /opt/app/logback.xml
ENV MODE="PRODUCTION"
VOLUME /log
WORKDIR /opt/app/
EXPOSE 80
CMD /etc/myservice/bootstrap.sh && /usr/lib/jvm/latest/bin/java
-cp /opt/app/core.jar:/opt/app/lib 
-Xms256m 
-Xmx2048m 
-XX:+UseCompressedOops 
-XX:+UseG1GC 
-Dspark.kryoserializer.buffer.max.mb=128  -
Dlogback.configurationFile=/opt/app/logback.xml 
org.mycompany.app.Runner
Ready, set,go
• docker build -t mycompany/app:1.0
• docker tag -t mycompany/app:1.0
registry.mycompany.com:5000/mycompany/app:1.0
• docker push
registry.mycompany.com:5000/mycompany/app:1.0
Container entrypoint
• Container must have long leaving process -
entrypoint
• Container will become stopped when process is
ended/crashed
• Two strategies: process per container vs
supervisord
Supervisord configuration
[supervisord]
nodaemon = true
logfile = /var/log/supervisord.log
[program:hadoop-hdfs-namenode]
command = /etc/init.d/hadoop-hdfs-namenode start
[program:mesos-master]
command = /usr/local/sbin/mesos-master --work_dir=/mnt/mesos-work --
hostname={{ MESOS_HOSTNAME }} --log_dir=/var/log/mesos
[program:vw-spanning-tree]
command = /usr/local/bin/spanning_tree
FROM mycompany/mesos-general
MAINTAINER mycompany
#Configure namenode
RUN apt-get install -y hadoop-hdfs-namenode=2.5.0+cdh5.3.3*
#Add config templates
ADD hadoop-conf/core-site.xml /etc/hadoop/conf/core-site.xml.tpl
ADD hadoop-conf/hadoop-env.sh /etc/hadoop/conf/hadoop-env.sh
ADD hadoop-conf/hdfs-site.xml /etc/hadoop/conf/hdfs-site.xml.tpl
ADD bootstrap.sh /bootstrap.sh
RUN chmod +x /bootstrap.sh
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf.tpl
CMD /bootstrap.sh && /usr/bin/supervisord
Master Dockerfile
#!/bin/bash
set -e
mkdir -p /mnt/mesos-work
mkdir -p /var/log/mesos
source /resolve_ec2_hostname.sh
envtpl < /etc/hadoop/conf/core-site.xml.tpl > /etc/hadoop/conf/core-site.xml
envtpl < /etc/hadoop/conf/hdfs-site.xml.tpl > /etc/hadoop/conf/hdfs-site.xml
envtpl < /etc/supervisor/conf.d/supervisord.conf.tpl > /etc/supervisor/conf.d/supervisord.conf
Bootstrap.sh example
• Container identification (--name)
• Network settings
o --net = [none, bridge (default), host, container:<name|id>]
o -P vs -p
o --link
• Useful options for debug/testing
o --rm=true, -it
o docker exec -it running_container_name bash
• Env variables
• Runtime constraints on CPU and memory
Run options
Environment example
Thank You!
References
● http://martinfowler.com/articles/microservices.html
● https://docs.docker.com/introduction/understanding-docker/
● http://domino.research.ibm.com/library/cyberdig.nsf/papers/092905219
5DD819C85257D2300681E7B/$File/rc25482.pdf

Docker based Architecture by Denys Serdiuk

  • 1.
  • 2.
    About Me 7+ yearsas backend Software Engineer. ● Java/Scala ● SQL/NoSQL databases ● distributed caches, queuing ● Hadoop/Spark ● AWS,DevOps ● REST, microservices
  • 3.
    An approach todeveloping a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms http://martinfowler.com/ Microservice architecture style
  • 4.
    • Component decomposition •Independant development lifecycle and technology freedom • Better extensibility • Fault isolation Microservice benefits
  • 5.
    • Deployment ofmuch greater number of services and components • Monitoring of many services for performance or issues • Looking into log files from many micro-services • Versioning between services and environment consistency Microservice drawbacks
  • 6.
    1. Multiple Serviceinstances per host ● conflicting resource requirements(CPU, memory, IO, etc.) ● conflicting dependency versions 1. Single Service instance per host ● potentially less efficient resource utilization ● hosts provisioning and maintenance 1. Service Instance per VM ● building a VM image is slow and time consuming 1. Service instance per container ● The infrastructure for deploying containers is not as rich as the infrastructure for deploying virtual machines Microservice deployment patterns
  • 7.
  • 8.
    Containerization providers Implementations: ● byvendors(Open Source,HP, IBM, Microsoft) ● by OS (Linux, FreeBSD, Solaris, Windows) http://en.wikipedia.org/wiki/Operating-system-level_virtualization#Implementations. Docker has become the most popular nowadays.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
    Basic docker usagescenario 1. create Dockerfile 2. build image with specific name in format [registry_url/]repository:imageTag , e.g myhost:5000/mycompany/myservice:version1 1. push image into registry (private or Docker Hub) 2. pull image by repository and tag (Optional) 3. run container from image
  • 15.
    Dockerfile • inherit existingimages • add/copy files to container • set environment vars • run shell command • expose ports • set working dir • share host FS with container • --no-cache option • CMD and bootstrapping • CMD vs ENTRYPOINT FROM mycompany/app-base:latest RUN mkdir -p /opt/app ADD core.jar /opt/app/core.jar RUN curl http://3rd-paty.repo.org/download/component.zip && unzip component.zip -d /opt/app/ && rm -f component.zip COPY lib/ /opt/app/lib ADD bootstrap.sh /etc/mysevice/ RUN chmod +x /etc/mysevice/bootstrap.sh ADD workspace-manager-core.jar ADD logback.xml /opt/app/logback.xml ENV MODE="PRODUCTION" VOLUME /log WORKDIR /opt/app/ EXPOSE 80 CMD /etc/myservice/bootstrap.sh && /usr/lib/jvm/latest/bin/java -cp /opt/app/core.jar:/opt/app/lib -Xms256m -Xmx2048m -XX:+UseCompressedOops -XX:+UseG1GC -Dspark.kryoserializer.buffer.max.mb=128 - Dlogback.configurationFile=/opt/app/logback.xml org.mycompany.app.Runner
  • 16.
    Ready, set,go • dockerbuild -t mycompany/app:1.0 • docker tag -t mycompany/app:1.0 registry.mycompany.com:5000/mycompany/app:1.0 • docker push registry.mycompany.com:5000/mycompany/app:1.0
  • 17.
    Container entrypoint • Containermust have long leaving process - entrypoint • Container will become stopped when process is ended/crashed • Two strategies: process per container vs supervisord
  • 18.
    Supervisord configuration [supervisord] nodaemon =true logfile = /var/log/supervisord.log [program:hadoop-hdfs-namenode] command = /etc/init.d/hadoop-hdfs-namenode start [program:mesos-master] command = /usr/local/sbin/mesos-master --work_dir=/mnt/mesos-work -- hostname={{ MESOS_HOSTNAME }} --log_dir=/var/log/mesos [program:vw-spanning-tree] command = /usr/local/bin/spanning_tree
  • 19.
    FROM mycompany/mesos-general MAINTAINER mycompany #Configurenamenode RUN apt-get install -y hadoop-hdfs-namenode=2.5.0+cdh5.3.3* #Add config templates ADD hadoop-conf/core-site.xml /etc/hadoop/conf/core-site.xml.tpl ADD hadoop-conf/hadoop-env.sh /etc/hadoop/conf/hadoop-env.sh ADD hadoop-conf/hdfs-site.xml /etc/hadoop/conf/hdfs-site.xml.tpl ADD bootstrap.sh /bootstrap.sh RUN chmod +x /bootstrap.sh COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf.tpl CMD /bootstrap.sh && /usr/bin/supervisord Master Dockerfile
  • 20.
    #!/bin/bash set -e mkdir -p/mnt/mesos-work mkdir -p /var/log/mesos source /resolve_ec2_hostname.sh envtpl < /etc/hadoop/conf/core-site.xml.tpl > /etc/hadoop/conf/core-site.xml envtpl < /etc/hadoop/conf/hdfs-site.xml.tpl > /etc/hadoop/conf/hdfs-site.xml envtpl < /etc/supervisor/conf.d/supervisord.conf.tpl > /etc/supervisor/conf.d/supervisord.conf Bootstrap.sh example
  • 21.
    • Container identification(--name) • Network settings o --net = [none, bridge (default), host, container:<name|id>] o -P vs -p o --link • Useful options for debug/testing o --rm=true, -it o docker exec -it running_container_name bash • Env variables • Runtime constraints on CPU and memory Run options
  • 22.
  • 23.
  • 24.
    References ● http://martinfowler.com/articles/microservices.html ● https://docs.docker.com/introduction/understanding-docker/ ●http://domino.research.ibm.com/library/cyberdig.nsf/papers/092905219 5DD819C85257D2300681E7B/$File/rc25482.pdf