When people sign up for Configuration Management Camp, we ask them what community room they are mostly interested in.
We ask this question because we have rooms in different sizes and we don’t want to put communities with 20 people showing interest in a 120 seat room and we don’t want to put a community with 200 people in a 60 seat room.
But it also gives us to opportunity to build some very interesting graph over the potential evolution of the communities.
I gave a couple of new and updated talks the last couple of months.
At Fosdem, I opened up the Distributions Devroom with a talk on how we could improve the collaboration between the developers of a distro, and their users, the ops folks. I seemed to not be the only person with similar ideas as the smart folks over at the CentOS project were already actively talking about their efforts into making some my ideas become reality the day before at the CentOS Dojo.
There’s been a lot of discussion about the sillynes of the term BiModal IT, aka the next big thing for IT-organisations that don’t dare to change, but still want to sound cool.
So here is my idea to reuse that term for something relevant.
BiModal IT, is the idea where you take a fully automated infrastructure which has been build on the principles of Infrastructure as Code. Which gets periodic idempodent updates (e.g every 15 or 30 minutes, or when you orchestrate it), and consistency checks , where the source code for that infrastructure is versioned , tested and delivered trough a traditional Continuous Delivery pipeline for the majority of your services. and add realtime reconfiguration capacities based on service discovery for the other services that really change fast, or in a real elastic way, using tools like Consul, Consul_template, etcd etc..
Software delivery is hard, plenty of people all over this planet are struggling with delivering software in their own controlled environment. They have invented great patterns that will build an artifact, then do some magic and the application is up and running.
When talking about continuous delivery, people invariably discus their delivery pipeline and the different components that need to be in that pipeline.
Often, the focus on getting the application deployed or upgraded from that pipeline is so strong that teams
forget how to deploy their environment from scratch.
A couple of months ago we were seeing weird behaviour with consul not knowing all it’s members at a customer where we had deployed Consul for service registration as a POC
The first couple of weeks we hadn’t noticed any difficulties but after a while we had the impression that the number of nodes in the cluster wasn’t stable.
Obviously the first thought is that such a new tool probably isn’t stable enough so it’s expected behaviour , but rest asured that was not the case.
Steve Ropa blogged about What done looks like in devops , I must say I respecfullly , but fully disagree with Steve here.
For those of you that remember I gave an Ignite about my views on the use of the Definition of Done back ad #deovpsdays 2013 in Amsterdam.
In the early days we talked about the #devops movement partly being a reaction against the late friday night deployments where the ops people got a tarball with some minimalistic notes and were supposed to put stuff in production. The work of the development team was Done, but the operations team work just started.
If it’s not broken , don’t fix it.
Those who don’t understand Unix are doomed to reinvent it, poorly
Complexity is the enemy of reliability.
Are some of the more frequently heard arguments in the systemd discussion. Indeed I see and hear a lot of senior Linux people react openly and probably way to late against the introduction of systemd in a lot of our favorite Linux distributions.
To me this is a typical example of the devops gap. The gap between developers writing code and operations needing to manage that code on production platforms at scale.
Often developers writing code that they think is useful and relevant while they are not listening to their target audience , in this case not the end users of the systems but the people that are maintaining the platforms. The people that work on a daily base with these tools.
After not being able to give my planned Ignite at #devopsdays Amsterdam because I was down with the flu here’s some fresh opportunities to listen to my rants :)
In September I`ll be talking at PuppetConf 2014, San Francisco , USA about some of the horror stories we went trough over the past couple of years when deploying infrastructure the automated fasion.
Just one week later I`ll be opening the #devops track at DrupalCon Amsterdam together with @cyberswat (Kevin Bridges) where we’ll talk about the current state of #drupal and #devops , We’ll be reopening the #drupal and #devops survey shortly, more info about that later here..
1. yum install docker
3. docker run --rm -i -t -e "FLAPJACK_BUILD_REF=6ba5794" \
4. > -e "FLAPJACK_PACKAGE_VERSION=1.0.0~rc3~20140729T232100-6ba5794-1" \
5. > flapjack/omnibus-ubuntu bash -c \
6. > "cd omnibus-flapjack ; \
7. > git pull ; \
8. > bundle install --binstubs ; \
9. > bin/omnibus build --log-level=info flapjack ; \
10. > bash"
11. docker - version 1.5
12. Copyright 2003, Ben Jansens <ben@orodu.net>
14. Usage: docker [OPTIONS]
16. Options:
17. -help Show this help.
18. -display DISLPAY The X display to connect to.
19. -border The width of the border to put around the
20. system tray icons. Defaults to 1.
21. -vertical Line up the icons vertically. Defaults to
22. horizontally.
23. -wmaker WindowMaker mode. This makes docker a
24. fixed size (64x64) to appear nicely in
25. in WindowMaker.
26. Note: In this mode, you have a fixed
27. number of icons that docker can hold.
28. -iconsize SIZE The size (width and height) to display
29. icons as in the system tray. Defaults to
30. 24.
33. [root@mine ~]# rpm -qf /bin/docker
34. docker-1.5-10.fc20.x86_64
35. [root@mine ~]# rpm -qi docker
36. Name : docker
37. Version : 1.5
38. Release : 10.fc20
39. Architecture: x86_64
40. Install Date: Sun 03 Aug 2014 12:41:57 PM CEST
41. Group : User Interface/X
42. Size : 40691
43. License : GPL+
44. Signature : RSA/SHA256, Wed 07 Aug 2013 10:02:56 AM CEST, Key ID 2eb161fa246110c1
45. Source RPM : docker-1.5-10.fc20.src.rpm
46. Build Date : Sat 03 Aug 2013 10:30:23 AM CEST
47. Build Host : buildvm-07.phx2.fedoraproject.org
48. Relocations : (not relocatable)
49. Packager : Fedora Project
50. Vendor : Fedora Project
51. URL : <a href="http://icculus.org/openbox/2/docker/<br />
52. Summary" title="http://icculus.org/openbox/2/docker/<br />
53. Summary">http://icculus.org/openbox/2/docker/<br />
54. Summary</a> : KDE and GNOME2 system tray replacement docking application
55. Description :
56. Docker is a docking application (WindowMaker dock app) which acts as a system
57. tray for KDE and GNOME2. It can be used to replace the panel in either
58. environment, allowing you to have a system tray without running the KDE/GNOME
59. panel or environment.
60. [root@mine ~]# yum remove docker
61. [root@mine ~]# yum install docker-io
63. Installed:
64. docker-io.x86_64 0:1.0.0-9.fc20
66. Complete!
