2. Ruby, Java, C Developer turned into DevOps Architect
Contributed to Chef development
Chef azure extension
Knife plugins: knife-azure, knife-ec2, knife-openstack
Knife WinRM, knife windows listener
Working with iHealth Technologies
Technology, innovation and the thirst to keep learning are what define me
Love to travel, read, write
Above all, I am a mother to two boys!
@muktaa
3. Docker
Chef + Docker
CD pipeline that uses knife-ssh
Push Jobs
Chef Cookbook
Chef Containers
Our Story
11. Control the environment Vs System Image /
Runtime image
Tradeoff between flexibility and manageability
CM is the vein of DevOps
Shell scripts -> Chef
Immutable Infrastructure
13. Replaces Human Tasks,
Idempotence,
Thick client - thin servers,
Order Matters,
Huge Community Support
An improved Robot,
Fast,
Easy,
Fresh fish in the market,
ready to be baked!
15. •git push
•Triggers
Build
Code
•Build tools
have docker
support
•Build tools
generate a
docker
image
Build
Process Save imageDocker
Image Unique tagDocker
Registry
•docker pull
•docker stop
•docker run
Deploy
using knife-
ssh or Push
Jobs
CI Server
16. git push to https://github.com/muktaa/HelloScala
Triggers a build on your CI server
sbt docker
docker push muktaa/hello-scala
knife ssh 'role:test' 'deploy.sh' -x ssh-user -i ssh-key -c knife.rb
Build tools offer docker integration
Eg: Maven has docker-maven-plugin
https://github.com/spotify/docker-maven-plugin
mvn clean package docker:build -DpushImage
17. ~/github/HelloScala > sbt docker
[info] Loading project definition from
/Users/muktaaphale/github/HelloScala/project
[info] Set current project to hello-scala (in build
file:/Users/muktaaphale/github/HelloScala/)
[info] Creating docker image with name: 'muktaa/hello-scala'
:
[info] Sending build context to Docker daemon
[info] Step 0 : FROM dockerfile/java
[info] ---> 1126c85d8a06
[info] Step 1 : ADD /app/hello-scala_2.11-1.4-one-jar.jar
/app/hello-scala_2.11-1.4-one-jar.jar
[info] ---> Using cache
[info] ---> 61871958f108
[info] Step 2 : ENTRYPOINT java -jar /app/hello-scala_2.11-1.4-
one-jar.jar
[info] ---> Using cache
[info] ---> a8005b32ddc4
[info] Successfully built a8005b32ddc4
[info] Successfully built Docker image: muktaa/hello-scala
[success] Total time: 1 s, completed Mar 3, 2015 2:10:04 PM
~/github/HelloScala > docker images | grep hello-scala
muktaa/hello-scala latest a8005b32ddc4 12 hours ago
715 MB
~/github/HelloScala > docker run muktaa/hello-scala
Hello, world! #1
Hello, world! #2
Hello, world! #3
20. Knife-ssh works like “push”. Almost.
Journey from pull to push
“Chef push jobs is an extension of the Chef server that allows
jobs to be run against nodes independently of a chef-client
run”
Job: set of commands to be run on node
Docker pull
Docker stop
Docker run
21. Push Jobs
Use message bus (zeromq)
Claims to attack the scalability
issue
Deployment status is relayed
back
New born baby
Complex at the moment, ready
with just the basic foundation
Knife SSH
Parallel ssh
SSH Protocol is slow and CPU
hungry at scale
Feedback on deployment status
is not as easy
Been in the market for long
Easy to use
22. Enterprise Chef 11 or Chef server 12
Standalone or HA
Run the commands on Chef Server:
chef-server-ctl install opscode-push-jobs-server
opscode-push-jobs-server-ctl reconfigure
chef-server-ctl reconfigure
23. Install knife push plugin
Gem install knife-jobs
Knife cookbook site download push-jobs
Extract and save to your cookbook path
Edit the attributes file (push-jobs/attributes/default.rb)
default['push_jobs']['package_url'] = 'https://opscode-private-
chef.s3.amazonaws.com/ubuntu/12.04/x86_64/opscode-push-jobs-
client_1.1.5-1_amd64.deb'
default['push_jobs']['package_checksum'] =
'd659c06c72397ed2bc6cd88488349857f1958538‘
Upload the push-jobs cookbook to your ChefServer
24. Create 2 groups
Pushy_job_writers
Pushy_job_readers
Add user to the groups
Sudo chef-client –r “recipe[push-jobs]”
From Workstation:
Knife node status
Knife node status <node-name>
36. # Build a docker image using docker_image
resource
docker_image node['docker']['image'] do
tag node['docker']['image']['tag']
source '/var/docker'
action :build
end
# Push the image to docker registery
docker_image node['docker']['image'] do
action :push
end
# Delete the image from the machine
docker_image node['docker']['image'] do
action :remove
end
37. # Run Container
docker_container ‘muktaa/hello-scala’
detach true
port ‘8081:8081’, ‘8085:8085’
env ‘ENVIRONMENT=pre-prod’
volume ‘/mnt/docker/docker-storage’
action :run
end
38. # Generate a docker file using template.
template "#{node['docker']['directory']}/Dockerfile" do
source 'dockerfile.erb'
variables image: node['docker']['base']['image']['name'],
maintainer: @docker_cred['maintainer'],
email: docker_cred['email'],
build_cmd: node['docker']['build']['commands'],
entry_point: node['docker']['build']['entry_point']
action :create
end
39. Build
Application
• Save the Artifact to a Repository
Manager
Build
Docker
Image
• Docker cookbook would build and save
the docker image
Deploy
• Docker cookbook runs
the container on the
nodes
43. Bootstrap chef-client without SSH
connection
Manage multiple services inside your
container
Manage running state of your container
Consistency across Architectures
Mixed Architecture Applications
44. Transitioning traditional architecture to containers
Handling last mile configuration when container boots
Getting the best of two worlds without complexity
45. Gem install knife-container
knife container docker init
NAMESPACE/IMAGE_NAME [options]
-f base docker image (default is ubuntu 12.04) - chef
container should be already installed on it
-r runlist
-z chef client local mode
-b use berkshelf
46. $ sudo knife container docker init muktaa/hello-scala-cc
Compiling Cookbooks...
Recipe: knife_container::docker_init
* directory[/home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc] action create
* template[/home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc/Dockerfile] action
create
- update content in file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/Dockerfile from none to 943017
- * template[/home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc/.dockerignore]
action create
- create new file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/.dockerignore
- update content in file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/.dockerignore from none to e3b0c4
* directory[/home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc/chef] action
create
- create new directory /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc/chef
* template[/home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc/chef/client.rb]
action create
- create new file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/chef/client.rb
- update content in file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/chef/client.rb from none to 7de61f
* file[/home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc/chef/first-boot.json]
action create
- create new file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc/chef/first-
boot.json
- update content in file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/chef/first-boot.json from none to 5269ef
* template[/home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc/chef/.node_name]
action create
- create new file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/chef/.node_name
- update content in file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/chef/.node_name from none to 4764d2
* template[/home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc/Berksfile] action
create (skipped due to only_if)
* directory[/home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc/chef/secure]
action create
- create new directory /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/chef/secure
* file[/home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/chef/secure/validation.pem] action create
- create new file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/chef/secure/validation.pem
- update content in file /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-
cc/chef/secure/validation.pem from none to ec1f3e
- change mode from '' to '0600'
Downloading base image: chef/ubuntu-12.04:latest. This process may take awhile...
Tagging base image chef/ubuntu-12.04 as muktaa/hello-scala-cc
Context Created: /home/ubuntu/chef-repo/dockerfiles/muktaa/hello-scala-cc
52. Running apps in containers is easy
Debugging apps in containers is difficult
You can very well run multiple services inside a
docker container
Ah the woes of Docker networking!
Sequential Progression
Bake carefully… Happy Baking!
Hello Chefs! Good afternoon!
I will be talking about using Docker with Chef! Baking docker using chef!
Currently I am working with IHT. At IHT we are building a new product with an exciting technology stack. The product is primarily written in Scala, uses Akka framework and Triple store (triple rush). Similarly We are implementing a solid DevOps strategy.
My job and role perfectly suits my passion for technology, innovation and the thirst to keep learning.
Flew 20 hrs from india
We will go through a quick introduction to docker
Why Chef and Docker are needed together to build an awesome solution
We will Build a very simple CD pipeline that uses knife-ssh
Quickly delve into using push jobs , quickly since yesterday we had a very good session on push jobs by
See how we can Use the docker chef cookbook to manage docker
And Conclude with Chef Containers
lightweight virtualization provided by libraries inside linux kernel
Docker engine is a portable, lightweight runtime and packaging tool
Docker Hub: is a cloud service for sharing applications and automating workflows
Docker images: layered file system
guest operating system - which may weigh 10s of GB.
Docker runs as an isolated process in userspace on the host operating system, sharing the kernel with other containers. Thus, it enjoys the resource isolation and allocation benefits of VMs but is much more portable and efficient.
dockerfiles help you codify your configuration, its a set of bash commands which results in a docker image. Docker images are diff to maintain. not idempotent
This is a very basic example of config management done inside docker image.
Consider repo HelloScala with a dockerfile & Hello-scala.conf. The right side shows the dockerfile which picks up the conf and uses it for the apache config.
There is a need to do high quality config management inside docker images, while taking advantage of the many benefits docker containers provide.
Example –
*instead of long bash script in your dockerfile, you can use chef recipe
*if you have already invested in chef, don’t have to make big changes
Shared Hosting – PaaS
Many hosted CI servers like Travis-CI or internet search providers use Docker for infrastructure virtualization and application isolation
Microservices
microservices architecture has small services which have independent deployment but depend on each other. Docker provide an ideal environment for deployment of these services with respect to speed, isolation, and lifecycle ,management.
Lightweight Testing
Docker is widely used in testing applications. Docker containers can be destroyed post testing and new ones are created for every test run.
*There is support in test kitchen to test cookbook inside docker containers
we want to automate everything. In DevOps. Iteratively progress to achieve automation
We want to include all the awesome features. We want to ensure we stay in the market even after a couple of years. And that IS an important consideration - when the industry and technology are moving at such a fast pace!
We want to do it all.. and yet deliver on time!
We can achieve this is by defining a solution that would give us the best of both the worlds!
Chef Vs Docker is like considering CM Vs golden images.
With CM you can control the environment by using tools like Chef.
Docker belongs to the school of golden-images which favours clones of a single and well maintained system image.
Generally, people look down on Golden Images as The state of the machine tends to change over time and becomes an unmanageable mess. Golden images were gradually discarded for more advanced methods of config management!
But having said that, golden images have been pulled off successfully for a long time.
Now With Docker or containerization generally, the concept of immutable infrastructure has again come to the fore. Immutable infrastructure is a stack that you build once, run any number of times as new instances, and never change again. If you want to change deployment then you need to terminate the instance or container and start over from step one: that is, build a new image.
Docker attacks a subset of problems in DevOps, while an umbrella of solutions is provided by Chef. Lets see why & how we can do that
Complementary
Chef was born to replace human tasks. It was based on 3 core principles: idempotence - configuration should be defined such that it can run on any machine, “pull” philosophy thereby maintaining a thin server, and the importance of the order in which the configuration is defined. Chef grew up to be one of the most prefered CM tools, with a large community contribution. Its tried and tested. Its safe.
Then came the container era. Containers are faster. With Docker, there have been debates that complex CM tools are not needed. Docker makes your life simpler, they say. But Docker is new and not as much explored. There is risk in getting docker to production.
Lets bake the fresh fish into a hot and healthy meal!
Consider you have a github repo which triggers build on your CI server with a git push.
Most of the build tools now have docker support. With a successful build & maybe tests, a docker image is created by the build tool. The docker image can be saved to the docker registry. It can be given a unique tag in the docker registry.
This docker image needs to run on your node. As we know, it is just 3 commands that need to run: docker pull latest images (or pull a particular tag), stop the running container, start a new container. Note – docker stop may or may not be needed, or it can be stopped later as per the requirement or design.
How can you take your deployment to your nodes?
Use knife-ssh!
Here are the steps in detail, of how this can be done.
A sample demo project, HelloScala triggers a Travis-CI build. SBT is “scala build tool”.
Sbt docker command creates a docker image.
Muktaa/hello-scala is a repo on the docker registry where we would save the docker images.
Other build toolsl ike maven offer docker integration too.
Run the command mvn docker:build to create docker image
That’s it!
Did I hear using Chef is complex? Esp in this particular case?
That’s how the command execution looks…
We talked about docker registry which woud save docker images. Docker hub provides a hosted docker registry. The links above show 2 different repos on the docker registry. We can setup automated builds in that registry. With git push, this build can be triggered, or the build can be triggered from your CI server using the API call. However this feature is in a crude phase with very less flexibility, it takes a long time for the docker image to build.
You can setup the docker registry in your data centre too. It works very similar to the docker hub.
The CD pipeline we saw last was almost like a push model. Almost. Because the changes were pushed into the node by the CI server and not your chef server!
The world seems to be going round and round, traversing the same path again and again! Golden images are coming back. Chef too had a reason for the pull model, to keep the server “thin”. But the changing challenges demand that there is a need for a pull model. So chef has introduced push jobs by keeping the server is thin!
Chef push jobs is an extension of the Chef server that allows jobs to be run against nodes independently of a chef-client run – that’s how push jobs are defined.
A job is a set of commands that need to be run on the target node. From docker perspective the commands are docker pull, stop & run.
As mentioned in the previous slide, push jobs fit in the real “push model”.
<Read out the diff>
You need either Enterprise Chef or Chef Server 12. It relies on the ACL system that was open sourced with Chef Sever 12. Also, the install command was introduced with Chef Server 12.
Push Jobs does not work with Open Source Chef Server 11.
Can be setup as standalone or as HA
Run the commands on your chef server, to set it up to use the push jobs feature.
Install the knife push plugin
Push jobs cookbook would be used. So download it from the site or git clone the cookbook. You would have to fetch its dependency cookbooks as well. Update the attributes to add the push jobs package URL and checksum as mentioned.
Upload the cookbook to your chef server
Simply run the chef client with the recipe
Run the knife node status commands to check the node status. It will just show the status “available” at this stage which confirms that the node is prepared for push events.
Create the pushy_job_writers and pushy_job_readers on the organization of the Chef server and add your workstation user to that group.
Knife-ssh won for us. Push jobs need to mature. They are still under development and complex to implement.
I believe if people are comparing Ansible with Chef for this feature, it should be compared with knife-ssh!
We looked at the demo use case, but in actuality the systems are complex
Docker image is made up of the Application and the configuration.
By configuration, we mean the setups needed for the application to run as well as the environment specific configuration.
Packages: apache.
Softwares: jdk
Files: xml
Log levels
Eg: There is a database that the application reads. This DB is different for the 3 environments.
Consider the case where the application reads some reference data. This ref data source and volume varies in all environments.
More specifically consider an Akka cluster, which is a group of nodes and few nodes are defined as the SEED nodes. This akka config is different for diff environments
Docker containers that host the application, or components of the application. The workflow is such that the docker containers need to be deployed continuously to diff environments. Dev, pre prod and prod. Each env has a different configuration.
Now also consider the case, that initially the docker container runs on DEV. When its performance meets expectations, it needs to be promoted to the pre prod and then to the prod env. Since the environment conf is embedded inside the docker image, any idea how we can promote the docker container from DEV to preprod?
Docker containers can run on any machine or VM so the “environment” should not matter, you say? Let me explain further...
Managing Credentials is an unsolved problem with Docker today
Hard coding or setting variables is not secure, they are the workarounds.
So if in the prev slides you thought you could pass the configuration to the docker containers, then reconsider the approach for passing the credentials in that manner! Well, one can be adamant and find workarounds, which would only get more complex.
If you decide to use Chef, this can be managed using databags.
This worked well for us, until we had to keep making changes to the configuration
The docker cookbook is available in chef supermarket
Using it, you can install docker, build docker images, commit & push to docker registry, pull image and run container.
For the docker image management and deploy, the 3 LWRPs are useful.
Using lwrp docker_image to build and push the image to docker registry
Elegant and working solution
Package that provides config managemet for your containers
chef-client
Latest chef-client that runs within the container.
runit - RUNit - lightweight cross-platform init scheme to ensure all child processes are properly managed
chef-init - root process which can launch and manage multiple processes inside a container. It is custom built by chef.
Each OS has an init.
docker replaces the init of the OS. chef-init runs as PID1 and delegates managing child processes to runit.
Bootstrap the chef-client without an SSH connection
Manage multiple services inside your container
Use the knife container plugin to work with Linux containers; use the docker build and docker init arguments to manage Docker image contexts
Use chef-client resources the same way in a container as on any UNIX- or Linux-based platform
Consistency across architecgures – you don’t need different CM tools for Physical, virtual, or machines on cloud. If you have invested in Chef already which runs for you on a physical machine you leverage the same config on chef container
Mixed architecture. You might be using docker for development or test environments. But not in production. If you use chef containers for your dev & test env but physical machines on production, then it is lot easier to manage the config on each, as the config is idempotent if you use Chef for CM.
transitioning trad architecture to containers - all you need is the chef run list, it can run on bare metal, VMs or containers.
handling last mile config when container boots - registering an agent you need for monitoring maybe, or some env specific changes. e.g.: in our DEV env we read some reference data which is a truncated version of the real data while in the test env its a full blown test data. and in prod it is the real data & not the synthetic test data.
Using chef containers is not complex. You can define container configuration using chef recipies instead of long bash scripts
Chef container can be used to manage docker images. You can set certain services to launch when the container launches using the enable action of the chef resource. When chef-init starts, it can launch chef-client and you can configure which service you want to start using start action of the chef resource.
1. install knife-container gem
knife container is the only command needed to manage the docker lifecycle
2
Knife container docker init creates the docker context which comprises of docker components and chef components
To initialize the Docker context, use the init command. The knife container uses a folder called dockerfiles to organize all the Docker contexts that you manage. By default, the dockerfiles folder is created in your chef repo.
To initialize the Docker context, type the following command:
Pass in your image name (in this example,demo/apache2), a run list, a –zand a –b. The –z is for local mode and the –b says to generate a Berksfile.
Note step 2: chef-init —bootstrap (this runs the chef-client)
step 1: adds the chef dir to /etc/chef
step 0: & last tag: only 1 copy of the image, see docker images
so we created an image from ubuntu 14.04 and created image, the new image will have same tag but diff image id.
Our product is still under development. It is not yet live.
So how easy can you imagine the DevOps work would be?
6 man years of code. All developed by pure developers, without any Ops or systems idea.
We had to start at: how do we run the application?! We had to figure out how to run using SBT – the scala build tool!
And just while we figured out how to run it, the product architecture gets changed. And the process continues.
It was not difficult to get the application working as docker. We used the scala build tool to create docker images that ran as docker containers and that ran rather well.
But there were a couple of lessons we learnt…
We will be using containers, we are planning to use mesos.