Everything is a Freaking DNS problem - image sprawl http://127.0.0.1:8080/blog/taxonomy/term/1244/0 en Docker vs Reality , 0 - 1 http://127.0.0.1:8080/blog/docker-vs-reality-0-1 <p>(aka the opinionated summary of the #devopsdays London November OpenSpace on , Containers and the new flood of Image Sprawl)</p> <p>There's a bunch of people out there that think I don't like docker, they are wrong.</p> <p>I just never understood the hype about it since I didn't see, (and still don't) see it being used at large and people seem to understand that as being against it.</p> <p>So let me put a couple of things straight :</p> <p>There's absolutely nothing wrong with using a <strong>container</strong> based approach when deploying your infrastructure. If you remember my talks about the rise of Open Source Virtualization some years ago you've noticed that I've always mentioned OpenVZ and friends as good alternatives if you wanted to have a lot of isolated platforms on one machine. LXC and friends have grown .. they are even more usable these days. Years ago people bought bare metal and ran Hypervisors on it to isolate resources. These days people rent VM's and also want the same functionality so the use of the combination of Virtualization and Container based technologies is a very good match there.</p> <p>There's also nothing wrong with using Infrastructure as Code tools to build an reproducable image you are going to deploy will provide you with a disposable image which allows you to quickly launch a reproducable and versionned platform for your application if that application is supposed to be shortlived. The tooling around today is not yet there to have these images long lived as you still need to manage the config inside the containers as your application will evolve, it will change, your environment will change (think even about changing to a different loghost..) , but when you don't have to keep state you can dispose the image and redeploy a new reproducable one.</p> <p>In the embedded world, this kind of approach with multiple banks has been a round for a while , one image running, a second bank as a fallback, and when you upgrade the passive bank you can swap the roles and still have roll back.</p> <p>There's is also nothing wrong on combining these to approaches and using tools such as Docker and Packer. </p> <p>But there is lot wrong with building images that then start living their own life, tools like Veewee etc saw the light to create an easy way to make sure the JeOS image (Just Enough Operating System) we created was reproducable, not to ship around virtual appliances. </p> <p>But, lets be realistic, the number of applications that are suitable for this kind of environment is small. Most applications these days are still very statefull, and when your application contains state you need to manage that<br /> that state, you can't just dispose an image which has state. Specially in an Enterprise environment stateless, immutable applications are really the exception rather than the rule.</p> <p>When your application maps with stateless and short lived, or a some people like to call it Immutable please do so.. but if it doesn't please remember that we started using configuration management tools like CFengine, Puppet and Chef to prevent Image Sprawl and Config Drift<br /> There's proprietary businesses out there building tools to detect config drift and extort organisations to solve problems that shouldn't have existed in the first place.</p> <p>Luckily the majority of smart people I've spoken to over the past couple of weeks pretty much confirmed this ...<br /> Like one of the larger devops minded appliation hosting outsourcers in emea, I asked them how much % of their customer base they could all "Immutable" , exactly 0% was the answer.</p> <p>Image Based Container solutions are definitely not a one size fits all solution, and we have along way to go before we get there if at all ..</p> <p>Till then I like not to diffuse my attention to too many different types of deploying platforms, just not to make stuff more complex than it already is...as complexity is the enemy of reliability</p> http://127.0.0.1:8080/blog/docker-vs-reality-0-1#comments antipatterns newbies containers devops image sprawl images infrastructure as code jeos packer puppet puppetize virtualization Wed, 27 Nov 2013 21:36:07 +0000 Kris Buytaert 1090 at http://127.0.0.1:8080/blog To exaggerate , or not ... http://127.0.0.1:8080/blog/exaggerate-or-not <p>Sometimes you have to <a href="http://virtualization.com/guest-posts/2009/04/17/on-the-dangers-of-ovf/" rel="nofollow">step out of line</a> to get a message through just write a viewpoint down in totally black, ignoring the white parts.</p> <p>Earlier examples of these tricks were my rants on <a href="http://www.krisbuytaert.be/blog/node/713">raid</a> :) </p> <p>The original work title of the <a href="http://www.virtualization.com/" rel="nofollow">Virtualization.com</a> post actually was "VMWare, the New Microsoft, they gave us point and click and no clue for the user" But I selfmoderated that down to a more gentle title, not attacking a vendor :)</p> <p>I think the message got through ...</p> <p>Yes you get the,<a href="http://www.rationalsurvivability.com/blog/?p=757" rel="nofollow">"he must be joking"</a> feedback from some ,on one hand that accelerating the effect and on the other some people might think what an idiot , but that doesn't weigh up to the one person who realizes he should do integrity checks on OVF's too and other one that realizes he shouldn't randomly copy VM's back and forth while not checking where they come from ...</p> <p>So for clarity sake I`m in favour of OVF as an open standard, assuming it is wiseley used :) </p> <p>On a side note , One of the people commenting on <a href="http://twitter.com/beaker" rel="nofollow">Beaker</a>'s blog wondered if " he checks the signature of every piece of software he ever downloads" .. I let yum or apt-get do that for me..</p> <p>It's not all black and white , Hope you enjoyed the show however :)</p> http://127.0.0.1:8080/blog/exaggerate-or-not#comments cloudsec image sprawl ovf virtualization Mon, 27 Apr 2009 18:32:08 +0000 Kris Buytaert 904 at http://127.0.0.1:8080/blog