Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How We Use Docker For Continuous Delivery – Part 2

contino.co.uk

Post reply on HN
Print view View original

21–29 of 29 posts

Re: How We Use Docker For Continuous Delivery – Part 2

#21

Post by jessaustin »

kgilpin wrote: post #19

It seems like there is a high level of trust between micro-services, but it's not clear what is the basis of this trust. For example, is any service allowed full permissions on any other service? Is there authentication and authorization in the system?

The other Docker setups I've seen just go by port/host. This probably isn't enough, in many cases. Certainly you don't want to do that on a shared host.

Re: How We Use Docker For Continuous Delivery – Part 2

#22

Post by ah- »

fsaintjacques wrote: post #20
dorfsmay wrote: post #13

How do you deal with performance problem? In a classic "apps run on a known instance" model, when the instance starts having performance issues, I can ssh to it and use the usual tools (iosat, top, atop, netstat, etc...). With docker, how do you correlate instance/docker, and do perf analysis?

Couldn't you just connect to the master host? I'm not sure how namespacing is done inside the kernel, but I would assume that the host would have access to containers info.

Yes, at least with raw lxc containers that's the case. You can simply see the processes in the container in the host top.

Re: How We Use Docker For Continuous Delivery – Part 2

#23

Post by AdamMeghji »

dorfsmay wrote: post #13

How do you deal with performance problem? In a classic "apps run on a known instance" model, when the instance starts having performance issues, I can ssh to it and use the usual tools (iosat, top, atop, netstat, etc...). With docker, how do you correlate instance/docker, and do perf analysis?

Install the tools you need via the Dockerfile (iostat, top, atop, etc.), and an sshd. Then, instead of running the single web process, run supervisord via CMD, which will subsequently launch both your web app process, AND sshd. From there, EXPOSE 80 22, and you can SSH into the container to run any perf analysis tools as usual.

EXPOSE 80 22; CMD ["/usr/bin/supervisord"]

Re: How We Use Docker For Continuous Delivery – Part 2

#25

Post by dorfsmay »

fsaintjacques wrote: post #20
dorfsmay wrote: post #13

How do you deal with performance problem? In a classic "apps run on a known instance" model, when the instance starts having performance issues, I can ssh to it and use the usual tools (iosat, top, atop, netstat, etc...). With docker, how do you correlate instance/docker, and do perf analysis?

Couldn't you just connect to the master host? I'm not sure how namespacing is done inside the kernel, but I would assume that the host would have access to containers info.

Yes, you can, but then it means you need to keep track of which master your dockers are running on.

Re: How We Use Docker For Continuous Delivery – Part 2

#26

Post by fsaintjacques »

dorfsmay wrote: post #25
fsaintjacques wrote: post #20

Earlier quoted context omitted.

Couldn't you just connect to the master host? I'm not sure how namespacing is done inside the kernel, but I would assume that the host would have access to containers info.

Yes, you can, but then it means you need to keep track of which master your dockers are running on.

It's either tracking the slave you're on, or repackaging the whole linux userland in your container. I'd go for the first one.

Re: How We Use Docker For Continuous Delivery – Part 2

#27

Post by sionsmith »

Hey Ben,

Thanks for the updated post. Could you give us a little more information / git gist ;) on how you achieved this: > Docker registry doesn’t inherently support the concept of versioning, so we have to manually add it using the Jenkins version numbers. > shell scripting to ensure that only 3 were kept in place on each deployment,

Did this involve you appending the version numbers to the image tag? We have a pretty similar set up, and something which you might want to look at is the registry being a SPOF, if that is down then none of the new nodes created by the ELB can be provisioned - create an AWS autoscale group of 1 and assign it an elastic IP to ensure if it goes down the kind bots at Amazon will bring another up for you. (Will require some cloud-init scripting)

Re: How We Use Docker For Continuous Delivery – Part 2

#28

Post by sionsmith »

tburch wrote: post #16

What do you use in Jenkins to build your Docker images? Are they just Maven projects?

Ok not sure what Contino do, but you want to do something along the lines of the following:

- Build your java / maven projects as normal.

- Use the maven scm / release plugin to publish your artifacts to your internal maven repo (Nexus) we use.

- In your Dockerfile use wget and the Nexus REST api to pull the jar / zip whatever from the Maven repo. (https://maven.java.net/nexus-core-documentation-plugin/core/...)

- Install Docker publish image plugin for Jenkins (https://github.com/jenkinsci/docker-build-publish-plugin/blo...)

- Create a downstream project based on your java / build.

Once all that is set up, every time you do a push / check in a the Docker image in your registry should be update.

Re: How We Use Docker For Continuous Delivery – Part 2

#29

Post by sionsmith »

amatheny wrote: post #24

How do you determine which instances get which containers? Do you have use autoscaling groups or only the ELBs?

Again not sure how Contino do it but if your using autoscaling groups the best way todo this is pass in a bootstrap script (shell or ansible) into the group when creating it so that will pull down the correct images if more instances are needed. To give yourself some control, you should probably do what we do - pass a simple wget in which pulls an ansible playbook stored in S3 so we can change version numbers etc without taking down the whole group. I've found there are many ways todo this but keeping things simple helps alot.
Post reply on HN