Zuehlke
Article: Codify your Developer VMs!
I believe many people are already codifying their server infrastructure as code via Chef, Ansible, etc, but setting up Developer VMs in an automated fashion is probably something only few people do.
There is 45 minutes conference talk I have to prepare some slides / examples for, and I believe that some of that material could be reused here.
To be discussed in this article:
- why you want to do that, the problems you want to avoid and the benefits you gain
- how to do that, conceptionally (sth like 5 golden rules for setting up developer vms)
- maybe a mini example, or at least links to examples we have on our zuehlke github account
What do you think?
P.S. talk info below:
Title: Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr
Abstract:
Die Automatisierung von Server Systemen durch Configuration Management Werkzeuge wie Chef, Ansible, usw ist weit verbreitet. Gute Tipps zur automatisierten Erstellung von Entwickler VMs (= die Desktop Umgebung für die Entwickler mit IDE, Compiler, Build tools, usw) findet man jedoch eher selten. Dieser Vortrag versucht genau diese Lücke zu schließen, und zeigt einen Ansatz um mit Vagrant und Chef Entwickler VMs zu erstellen: warum das überhaupt nötig ist, wie man Entwickler VMs aktuell hält und dabei kontinuierlich (natürlich automatisiert) testet, und wie sie auf einfache Art und Weise verteilt werden können. Die genannten Beispiele sind Open Source und können direkt wiederverwendet werden.
Der Vortrag enthält mehrere Demo Anteile. Zielgruppe sind Entwickler, Architekten und alle die ein Interesse an konsistenten und reproduzierbaren Entwicklungsumgebungen haben. Die Code Beispiele sind in Vagrant / Chef DSL (Ruby), Grundkenntnisse in einer Programmiersprache s.
Word up! ;)
Can we work the immutable vs. mutable infrastructure argument in there and explain why we choose to go vanilla+provisioning for dev VMs?
@damphyr you mean why not setting them up manually and carefully crafted with love by hand?
Why did we choose vanilla+provisioning actually? (ssssshh, just wanna check if our arguments / reasoning matches ;-))
Immutable infrastructure is the part where when we require a new server/node/workstation we throw the old one away and create a new one in it's stead.
This works OK for production and server environments but in the case of development a typical Windows VM ways in at about 100GB which even in modern networks requires a significant time to replace.
The second argument for mutability/updateability is that said dev environments might contain work that has not yet been distributed (pushed back to the server). Requiring devs to take care of these transitions is an invitation to commit errors and waste work.
On the dev side we have two scenarios:
- New team member - Requires a brand new VM. It should be possible with a fresh OS install and the repo to produce a dev environment consistent with the rest of the team (we might have to define consistent here)
- Old hand: same procedure for setup should converge the current VM to the newest state.
In CI/Test/Production we should build them fresh, the immutable infrastructure paradigm works OK. When we see it pragmatically though, CI should behave exactly like the dev environment and incremental updates are much faster (we tend to load our CIs pretty heavily)
The compromise here is to automate VM creation, do it frequently and present a pre-built image for whatever target host we use.
And on the subject of target hosts: Using vanilla+provision allows us to serve any combination of bare-metal and hypervisor offered from one source of scripts. This might seem trivial, but anyone who had to request capacity from IT departments knows that difficulties arise analog to the amount of software you require pre-installed.
So, you're going to let me write everything? 😉
Yes, that was my evil plan ;-)
I got your point with immutable infrastructure, but imho it's really in CI where we have a special case of that.
If you are talking about immutable infrastructure on the server side that is debatable though, and imho rather a use case for containers / docker than for configuration management tools like chef etc (which try to keep an existing system in the configuration)
For that reason I wouldn't necessarily want to bring up immutable infrastructure here, since it's not a typical use case for config mgmt tools
Still, we need to make that point very clear that we want updateabikity of an existing system
(and one interesting part on CI is to also have a build which tests that an existing system is updateable vs fresh vanilla install)
PS: my talk got accepted so I anyway have to do something on this topic now ;)
Am 23.03.2017 2:09 nachm. schrieb "Vassilis Rizopoulos" < [email protected]>:
Immutable infrastructure is the part where when we require a new server/node/workstation we throw the old one away and create a new one in it's stead.
This works OK for production and server environments but in the case of development a typical Windows VM ways in at about 100GB which even in modern networks requires a significant time to replace.
The second argument for mutability/updateability is that said dev environments might contain work that has not yet been distributed (pushed back to the server). Requiring devs to take care of these transitions is an invitation to commit errors and waste work.
On the dev side we have two scenarios:
- New team member - Requires a brand new VM. It should be possible with a fresh OS install and the repo to produce a dev environment consistent with the rest of the team (we might have to define consistent here)
- Old hand: same procedure for setup should converge the current VM to the newest state.
In CI/Test/Production we should build them fresh, the immutable infrastructure paradigm works OK. When we see it pragmatically though, CI should behave exactly like the dev environment and incremental updates are much faster (we tend to load our CIs pretty heavily)
The compromise here is to automate VM creation, do it frequently and present a pre-built image for whatever target host we use.
And on the subject of target hosts: Using vanilla+provision allows us to serve any combination of bare-metal and hypervisor offered from one source of scripts. This might seem trivial, but anyone who had to request capacity from IT departments knows that difficulties arise analog to the amount of software you require pre-installed.
So, you're going to let me write everything? 😉
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Zuehlke/zuehlke-book/issues/24#issuecomment-288713271, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWUsM8z7yUKIaSirot8oPx--LcTvcnHks5rom8HgaJpZM4MR_S_ .
@tknerr very good point, I would propose that you not pack too much into one article, so if you also want to talk about the immutable infrastructure aspect, you might want to put that into a separate article, to keep the first article more simple.
Great discussion so far. @tknerr can youconfirm, that you will write the article? Or shall we put the "author wanted" label?
@tknerr can youconfirm, that you will write the article? Or shall we put the "author wanted" label?
Yes I will. At least I want to, definitely. What's the deadline, actually?
I'm drowning in project work currently and don't find the time right now :-/
Great! I expect the article to be written and reviewed by the end of August. So whenever you are not drowning...