Live data from Hacker News

Testing with Jenkins, Ansible and Docker

blog.mist.io

1–10 of 24 posts

Re: Testing with Jenkins, Ansible and Docker

#3
You should optimize your RUN commands. Every time you RUN in a Dockerfile, it creates a new filesystem layer. There's a hard limit (42, iirc) to the number of layers that Docker can support.

Instead of doing:

    RUN echo bar >> foo
    RUN echo baz >> foo
You could do:

    RUN echo bar >> foo \
        echo baz >> foo

Re: Testing with Jenkins, Ansible and Docker

#4
post #3

You should optimize your RUN commands. Every time you RUN in a Dockerfile, it creates a new filesystem layer. There's a hard limit (42, iirc) to the number of layers that Docker can support. Instead of doing: RUN echo bar >> foo RUN echo baz >> foo You could do: RUN echo bar >> foo \ echo baz >> foo

This limit is now higher(somewhere in the range of 100), and will eventually go away. Once this limit is gone, best practices will almost surely be one command per run.

Re: Testing with Jenkins, Ansible and Docker

#5
At the same time, we need to move fast with development and deliver updates as soon as possible. We want to be able to easily deploy several times per day.

Genuine question, not intended as any sort of troll: what benefits would people with this philosophy say their organisation gains from routinely deploying multiple times per day?

I have nothing against better testing tools or more efficient development processes, of course, and if you have a serious bug then being able to fix it as quickly as possible is obviously beneficial. I just don't understand where this recent emphasis on always trying to move fast has come from, or what kind of management strategy someone might use to take advantage of such agility.

Re: Testing with Jenkins, Ansible and Docker

#6
I've been using Ansible for a few production-related tasks lately, and think it's great. It provides the right level of abstraction, IMHO: you can crack open a playbook, read through it, and know exactly what it is doing. There's also a growing number of playbooks if you google around.

That said, the biggest downside I've seen with Ansible is reusable components. They have something called Galaxy in beta [1], which should help, although it feels a bit rough yet...

[1] https://galaxy.ansible.com/

Re: Testing with Jenkins, Ansible and Docker

#7

At the same time, we need to move fast with development and deliver updates as soon as possible. We want to be able to easily deploy several times per day. Genuine question, not intended as any sort of troll: what benefits would people with this philosophy say their organisation gains from routinely deploying multiple times per day? I have nothing against better testing tools or more efficient development processes,…

I found this article helpful in understanding the 'multiple times per day' motive.

http://martinfowler.com/articles/continuousIntegration.html

Re: Testing with Jenkins, Ansible and Docker

#8

At the same time, we need to move fast with development and deliver updates as soon as possible. We want to be able to easily deploy several times per day. Genuine question, not intended as any sort of troll: what benefits would people with this philosophy say their organisation gains from routinely deploying multiple times per day? I have nothing against better testing tools or more efficient development processes,…

I think the point is that deployments should be streamlined and we should not make such a big deal out of them as many of us used to.

If the code for a new feature is ready and all the tests pass, being able to deploy with the click of a button allows you to close the ticket right away and move on to the next task in line. Also, there's no need to coordinate with other developers that are about to finish their thing.

Overall, it's good for productivity and peace of mind, as streamlined deploys are less error prone.

Re: Testing with Jenkins, Ansible and Docker

#9

At the same time, we need to move fast with development and deliver updates as soon as possible. We want to be able to easily deploy several times per day. Genuine question, not intended as any sort of troll: what benefits would people with this philosophy say their organisation gains from routinely deploying multiple times per day? I have nothing against better testing tools or more efficient development processes,…

It is all about feedback loops. If you finish a feature and no one sees it for a month because your on a monthly roll, you don't know if it really works for them. And if it comes back and needs an improvement, you have to figure out what you were doing again. Two month iterations are hard to learn from.

Re: Testing with Jenkins, Ansible and Docker

#10
post #3

You should optimize your RUN commands. Every time you RUN in a Dockerfile, it creates a new filesystem layer. There's a hard limit (42, iirc) to the number of layers that Docker can support. Instead of doing: RUN echo bar >> foo RUN echo baz >> foo You could do: RUN echo bar >> foo \ echo baz >> foo

In my humble opinion, each layer should have a clear purpose: http://www.extellisys.com/articles/docker-layer-overload
Post reply on HN