Running a WordPress blog on OpenShift Origin

I used to run my blog(s) on OpenShift Online (v2) which was, for many reasons, a terrible use case for that platform and my OpenShift colleagues hated that people do that a lot. This is one of the reason why OpenShift Online (v3) enforces some sleep time for the running services - to prevent you from running blogs and generally "production" services on the free service. You can still do it, if you don't mind some downtime.

For blog though, downtime is generally a bad thing, so I started to look around to find a different place to put it. Obviously, I did not want to pay and I especially did not want to pay "per instance" as I am also running a blog for my mum. My though was to use some cheap webhosting, but that would mean I would have to setup thing the old way - mode 1, without containers and all the orchestration goodness.

I started to look for a cheap cloud provided where I could run a small server for couple dollars a month - I first went to DigitalOcean as I have some free credits there, then I found Linode and Alibaba which were cheaper for the same or a bit more powerful VMs. The plan was to deploy OpenShift Origin, use Grant's tutorial to migrate the WordPress and never care about it again.

I created a VM, started to play around with OpenShift there and then I thought: "Maybe I could use an old laptop and just run OpenShift in my closet". The laptop has 4 GB of RAM and 2 cores of CPU, so it's 2-4 times more powerful than the VM in the cloud. It does not have SSD, so the disk operations are not the best, but it works and for $5-10 dollars I save on the cloud VM, I can buy the SSD later if I need.

So I updated the old netbook to latest Fedora, downloaded OpenShift Origin client binary from Github and started the single-node cluster. By following the above mentioned migration tutorial I got my WordPress instance running in few minutes and fixing the A record for DNS gave me my nice URL as well. So far, so good.

I did not have much time when I set it all up late last year, so I just migrated my mum's blog as well and let it run. It worked like a charm and I thought that as soon as I get a bit of time, I'll simply fix some things that were not setup properly - like backups or what happens when the laptop restarts.

As life happens, I never got back to figure out the backup and restart stories, which resulted in a major cluster We are redoing electrical wiring in our building, which means there are some expected outages. The laptop generally survived them fine, until one outage took almost a whole day. The laptop turned off and with it both blogs.

I thought it'll be fine - I'll just boot it up and run the OpenShift cluster again. Easy, right? Basically, yes, it is, if you read the docs carefully and keep your etcd data out of the Origin container, because if you don't, once the container dies, the etcd - i.e. the database behind OpenShift and Kubernetes, is gone. Ok, well, not a great thing to happen, but I still had all my other data from blogs, so I just needed to run the containers again with the same host volumes.

Sadly, that turned out to be problematic as well, because MySQL container does not really like to be pointed to the old volume with a new deployment (I did not investigate why, although it might be interesting for MySQL OpenShift deployment developers..). So the database failed. I copied the database volume to a new directory and started to experiment on it - the idea was that if I can dump it, I could just run a clean deployment and then import the dump.

This approach seemed to be getting me closer to the goal until the point where I deleted the original data volume by mistake, which left me only with the already corrupted copy. Yay. So close! At that point, there was not much else to do than to start over and run from the 6 months old backups I made during the migration. Not great, but lessons learnt.

Well, let's start from scratch and do things right now! First, run OpenShift Origin with a proper set of parameters. Those will include things like "run from existing configuration", "store etcd on disk", "select specific path for volumes"...

/bin/oc cluster up --public-hostname=$ --routing-suffix=$ --use-existing-config --host-data-dir=$HOST_DIR --host-config-dir=$HOST_DIR/openshift.local.config --host-pv-dir=$HOST_DIR/openshift.local.pv --host-volumes-dir=$HOST_DIR/openshift.local.volumes

Next, make sure the cluster will get started on (re)boot, so that it comes back up if there is another electricity issue. For that I used a unit from Tobias Brunner's post. Now, let's reboot works!.

Next thing is backup. It does not make much sense to store backup on the same drive and I did not really want to upload everything somewhere to the cloud, so I just plugged in a USB Flash drive I got at some conference and created a systemd mount unit based on James Oguya's post. For the actual backup, I decided to simply rsync the directory, where I store all the OpenShift configuration, etcd data, PVs, etc. to the flash drive. I am not entirely sure it is the best solution or even a solution which will allow me to restore things easily and fully, but I hope it will..and I will test it at some point;). For the rsync backup I created a systemd timer and a one shot unit which the timer runs once a day. ArchWiki post helped with this step.

The last thing is to not only start, but also enable all those services, so that things get into the right state after reboot. I tried to reboot couple times and things seemed to work fine after that - it takes couple minutes to boot, start the cluster and deploy all the containers, so there is a downtime during reboot, but I can live with that.

Wish me luck so that I don't lose the data again and share your stories about how and what you run at home:).

Google Manifesto: James Damore is right

Disclaimer: All of the below is my opinion. I am not a linguist, I am not psychologist, I am not neuroscientist - I am a white male software engineer who values women and diversity. I can read and (hopefully) use common sense and I try to think about information neutrally yet critically before I make an opinion.

James Damore is right. I have no idea if he is right that men and women differ, but he is right. There is an "ideological echo chamber". I have no idea if it is in Google, but it definitely is present in our society. Why do I think so?

Go and read the full manifesto: Not articles which give opinion directly in the title like the one at Gizmodo. Read the first paragraph of the memo. Go back to title and read the title again. Then finish the manifesto. Ignore your prejudice about diversity (regardless if it's positive or negative). Just try to grasp what he is pointing out.

Here is what I got out of the text:

  • Diversity is good
  • There is a problem with free speech
  • Women are equally capable of doing engineering work as men (but they excel because of different qualities)
  • There is some evidence that men's and women's brain differ (although there is probably the same amount of evidence that it does not differ)
  • Diversity programs might not work
  • Diversity programs might widen the gender gap
  • No one is questioning costs and effectiveness of the programs
  • There are potential improvements (listed in the doc)
  • The most important part of supporting diversity is inclusiveness

I listed 9 points above and there is one which could insult women - stating men and women are different. I would be interested in the analysis of the most used keywords for the memo on the internet - I am sure anti-diversity would be one of the top.  But if you read it with open mind, you might find there is nothing against diversity. The author is mostly concerned about free speech, inclusiveness and openness in present world - and reactions to this memo only support the case. We often fight so-called anti-diversity opinions, just based on labels, not based on the context and intentions.

Another much used keyword would be "screed" or "rant", but look at it - it's well structured and supported by science studies (although you might not agree with them) which are linked as sources. If I look at what I normally read on internet (excluding some work stuff), this is closest to a scientific article I've read in a long time. And it actually encouraged me to read more on the topic, find studies, read scientists' opinions on the topic. I think from the pure writer's point of view, it's a good piece.

What is the conclusion then? I like the way James Damore presented his opinion. I agree with him that there is an "ideological echo chamber". I don't like how public reacted. I'd love to see more openness in how people consume information - and I have a long way to go to learn this skill properly myself.

EDIT: I am still researching what other have to say about the topic, so there might appear a list of articles I found interesting following these lines...

Containers: Resurrection vs. Reincarnation

This post is to share that I am coining new analogy about containers, cloud and orchestration. Everyone uses Pet vs. Cattle, some use Ant. vs. Elephant. These animal analogies are fine and describe how YOU behave to your machines/containers if something bad happens.

But it's also important to look at things from the other side - what actually happens to the app? How does it feel? How does it perceive world around itself?


In a good old Mode1 world things were simple. Some app died, so you went and resurrected it back to life. Sure, PID was different, but it was the same machine, same environment, same processes around it. Feels like home...


Then the cloud and container world appeared and people realised they don't want to bring dead things back to life (it might have something to do with all the scary zombie movies, I think). And so in container orchestration you just get rid of things that appear to be dead and then bring new ones to life. And you app is reincarnated instead of resurrected

Resurrection vs. Reincarnation.

Reincarnation is not completely new in IT world - it was already used in MINIX many years ago:). But I am coining this new analogy for containers context. Obviously, it's up to you now to share the wisdom and make sure people know who was the original prophet!

Forget resurrection, reincarnation is a way to go!


Jak jsem se stal překladatelem

Když už tu rozebírám svoji pracovní historii, nesmím zapomenout na to, jak jsem se na pár měsíců stal překladatelem a co mě to naučilo.

Kdysi dávno předávno jsem narazil na video Snídaně s Petrem Márou a Tomášem Hajzlerem a zaujalo mě to. Zkouknul jsem pár dílů. Tomáš Hajzler tam moc zajímavě mluvil o svobodě v práci, o tom, že by člověk měl dělat, co ho baví a tak podobně. Mluvil zajímavě, takže jsem si ho vygooglil a narazil na jeho blog, společnost Peoplecomm a facebookvý profil.

Něco jsem pročetl, zkouknul další videa, ale hlavně jsem zaznamenal zajímavou aktivitu na Facebooku, která mě upozornila na chystající se konferenci Svoboda naživo. Hodně mě to zaujalo, a tak jsem přemýšlel, že bych se tam zajel podívat. Když jsem ale zjistil, kolik stojí lístek (tuším to byly 4 000 Kč), chuť mě přešla. Během pár dní ale začali organizátoři pro konferenci shánět někoho, kdo by dokázal otitulkovat dva rozhovory v angličtině.

Přesně podle hesla "Fake it, till you make it" jsem napsal, že není problém a rád to udělám. Za odměnu jsem dostal vstup na konferenci. Byl to celkem boj, protože jsem nikdy titulky nedělal. Ne, že by to bylo nějak extra záludné, ale porozumět anglicky psanému textu (s čímž jsem problém neměl) a odposlouchat, o čem to ti divní lidi vlastně mluví, byl trochu rozdíl. Inu, povedlo se. Moje titulky zhlédlo pár stovek lidí na konferenci a všichni byli nadšení. Konferenci jsem si neskutečně užil a pro jistotu jsem se ještě zapojil do dalších částí organizace.

Co je ovšem důležité, udělal jsem si tam pár přátel (mimo jiné Petra Skondrojanise, který teď rozjíždí projekt CoCuMa, který naprosto žeru), což vyústilo v něco, co jsem nečekal. Po konferenci se mi ozvalo pár lidí (včetně Petra), že by měli nějaká videa, která by potřebovali otitulkovat a kolik že teda vlastně beru. Uznávám, že jsem neměl ponětí, jak nastřelit částku, která by dávala smysl pro mě i pro ně, ale povedlo se a dohodli jsme se.

Od té doby jsem přeložil pár videí měsíčně za slušné peníze. K tomu se přidaly i nějaké překlady textů. Pamatuju si na pár zakázek, kvůli kterým jsem vstával ve 4 ráno, abych před odchodem do práce stihl něco udělat. Pak jsem přišel a do půlnoci zase překládal. Fakt mě to bavilo.

Za rok jsem zase překládal pro Svobodu naživo a zase mi po konferenci přišly další nabídky. Bylo to super.

Pak ale nastaly 2 změny - práce v Red Hatu mě začala víc bavit a titulkování mě omrzelo - bylo to pořád stejné, takže jsem toho nechal. Ale byla to skvělá zkušenost a plyne z toho pár ponaučení.

Dělejte věci zadarmo

Nikdy jsem nebyl dobrý obchodník, ale od malička jsem se na všem snažil vydělat. Takže když jsem pak někdy ve 14 dělal první web za peníze, bylo to úplně špatně. Moc mi to tehdy ještě nešlo, takže ten web byl hrůza a chtěl jsem za to přehnané peníze. Neříkám, že bych ho s dnešními vědomostmi udělal zadarmo, ale možná bych si neřekl o peníze. A když, tak asi jen o něco symbolického.

Vyhovte lidem, i když je to zadarmo

Když už tedy budete něco dělat zadarmo, nepřemýšlejte o tom tak, že to díky tomu můžete odfláknout. Naopak, vydolujte ze sebe to nejlepší. Bude to vaše vizitka, vaše reklama a čím lepší to bude, tím spíš to váš "zákazník" ukáže dalším lidem a doporučí vás.

Dělejte, na co máte chuť, i když to neumíte

Nejsem profík v angličtině. Teď už je to lepší, ale zabralo to dva roky dennodenní komunikace v angličtině (psané i mluvené), abych si opravdu začal se svou angličtinou věřit. Když jsem se hlásil na ten první překlad na konferenci, dělal jsem to s vědomím, že to asi bude trochu boj a že mi možná slovník za těch pár dní přiroste k ruce.

Takže díky Tome, Petře a další, kteří jste mi dali okusit tuhle práci a naučili mě pár nových věcí o životě.

Kde jinde než v letadle

Stalo se mi to už dvakrát. Nemůžu si pomoct, ale přijde mi to úplně neskutečné a nepravděpodobné. Prostě si jen tak sedíte a najednou...

Poprvé to bylo, když jsem letěl z Londýna. Byl jsem dost mrtvej, protože jsem tam kromě šmatlání po památkách taky oslavil narozeniny, což byla tehdy docela zničující záležitost. Každopádně sedím a přemýšlím, co a jak až dorazíme do Brna, kam půjdu, co budu dělat, že budu muset vyprat...a najednou na mě někdo mluví. Ale tak jakože zvláštně. Tak nějak jako bychom se už dlouho znali. Ostřím, zmateně koukám a hele, kamarádka, kterou jsem už pár let neviděl. Věděl jsem, že zmizela do Anglie, ale jaká je pravděpodobnost, že poletíme stejným letadlem? Jestli někdo dáváte statistiku a chce se vám hledat počty letů a cestujících Ryanairu - do toho. Budu rád za nějaká zajímavá procenta.

Ok, uznávám, někdo kdo bydlel kousek od Brna a žije v Anglii a někdo, kdo bydlí v Brně a byl v Londýně na dovolené, se potkají. To není až tak šílené (zpátky ke statistice - je, ale ok). Zkusíme další případ.

Podruhé se mi podobná věc stala, když jsem letěl z Ameriky. Už to nezařadím ke konkrétnímu letu. Myslím si ale, že to byl let s přestupem ve Washingtonu a (jako už v podstatě tradičně) jsem letěl s Lufthansou. Zase si tak sedím a přemýšlím o tom, co jsem to v tom Westfordu vlastně řešil, koukám na filmy a jen tak mimochodem mrknu přes uličku. Hmm, ten pán je mi nějaký povědomý. Koukám dál (na film, ne na něj) a podvědomě se ho snažím zařadit. Začíná svítat (ne venku, mně) a já lovím v hlavě jeho složku z kartotéky - no jasně, můj vedoucí na stáži a posléze i vedoucí diplomky. Jako vážně? Chvilku se bavíme, a tak zjišťuju, že se přestěhoval do Texasu a letí na "dovolenou" do ČR. He?

Ok, ten let z Londýna ještě beru, ale tohle? Ono je to záludné proto, že těch letů z USA je fakt hafo. Spousta leteckých společností. Můžete letět do Prahy, nebo do Vídně. Můžete letět z různých měst. Nedokážu si ani představit, jak by se tohle počítalo, kolik by tam bylo proměnných a jak miniaturní pravděpodobnost by vyšla.

Každopádně, pokud jste někoho dlouho neviděli a máte pocit, že je na čase se s ním potkat, leťte někam. Máte větší šanci, než že ho potkáte v Brně na Svoboďáku;). Empiricky ověřeno.

Moje cesta (s) Red Hatem

Takže, je rok 2012, léto, mám narozeniny a dneska je můj první den v Red Hatu. Protáhli mě budovou, kterou už znám z Open Housu a má si mě vyzvednout můj peer - člověk, který mi poví, co a jak, ukáže mi, kde sedím, zajde se mnou pro počítač...

Po hodině čekání jsem to vzdal a šel si svého peera najít sám. Ukázalo se, že se zrovna vrátil z oběda, takže jsme pořešili počítač, místo a já se omluvil, že jako vím, že je můj první den v práci, ale (teď už ex)přítelkyně má zrovna promoci a že bych nutně potřeboval vypadnout. Ale můžu se tak za 3 hodiny vrátit. Prý to nemá cenu, ať přijdu zítra. Můj peer tu prý ale týden nebude. Inu což, poradím si.

Chaos nad chaos, ale úplně nejochotnější lidi, jaké jsem zažil. No a co, že mají kupu své práce? Stejně mi pomůžou a poradí se vším, s čím si nevím rady. (Může to být i těma mýma hlubokýma šedo-modrýma očima.)  Jo a mají tu kafe a sladkosti a nikdo na mě nekřičí, že to je jeho kafe;). Nastoupil jsem na pozici "Sustaining Package Maintainer". Podle popisu něco jako "budeš se starat o balíčky, o které už se nikdo starat nechce, případně o verze, o které už se nikdo starat nechce". No a aby to nebylo jen tak, hned jsem dostal na starost balíček grub-legacy. Takže něco, na co už všichni, kromě zákazníků, kašlou. Je to v Cčku, jsou v tom kusy Assembleru a zabralo mi půl roku zjistit, jak to vlastně funguje. Ale pár bugů jsem opravil (a taky jsem jednu verzi rozbil tak, že jsem se bál, že si pro mě někdo přijde a vyřídí si to se mnou osobně;) ).

Taky jsem dělal na systemd, takže jsem byl strašně cool, protože systemd všichni nesnášeli a já jsem všem vysvětloval, jak je to super. (Kdo mě zná: vidíte tu analogii s Dockerem? Asi je mi to souzeno.) Naučil jsem se pořádně v bashi, Cčko mi nešlo úplně stejně jako na výšce, ale naučil jsem se relativně rychle psát maily a komunikovat s lidmi - protože jsem byl takové PR našeho týmu (to víte, ajťáci a komunikace:-P). Později jsem se od svého tehdejšího šéfa dozvěděl, že mě vzal tak trochu proto, že jsem na pohovoru projevil správnou míru drzosti, která by mohla některým jedincům v jeho týmu prospět, kdo ví.2014 - 1

Pak jednou přišel můj současný manažer (tehdy to ještě nebyl můj manažer) s tím, že by chtěl, abych dělal asistenta jednomu z architektů. Že by na mě házel jednoduché úkoly a já bych se postupně naučil, co a jak dělá, a pak bych něco z toho přebral. Programovat mě nebavilo, psát maily a bavit se s lidmi jo a zdálo se, že moje práce by se tou změnou pozice mohla od prvního přesunout ke druhému. A tak proč ne, že?

Začal jsem dělat tak-trochu-architekta. Srandovní část přišla, když mi onen architekt řekl, že za 14 dní odchází (po asi 14 dnech, co jsme spolu pracovali, určitě to nebylo kvůli mně). Asi si dovedete představit reakci: "Aha, ehm..mhm..a jakože, jako..jako já? Co?". Dozvěděl jsem se, že nejlepší by bylo, kdybych to po něm rovnou přebral všechno. Málem mě šlehlo, manažera málem šlehlo, všichni se mi smáli, někdo vypadal, že mě lituje... No ale, byl ze mě architekt, no. Tedy přesněji Lead Infrastructure Engineer. Což je název pozice, u níž mi dodnes nikdo nevysvětlil, co znamená. Ale myslím, že šlo jen o to vymyslet něco natolik nejasného, že mi to dá šanci na první téma k diskuzi s kýmkoliv se potkám. Jo, a začali mi říkat mini-Bill (protože ten architekt se jmenoval Bill).


Tak jsem pár týdnů zuřil, protože jsem se rozhodl, že budu skvělý architekt, což vyústilo v to, že jsem úspěšně objevil nespočet kostlivců, které jsem musel vyřešit. Nejvtipnější na tehdejších diskuzích bylo, že jsem se samozřejmě ptal různých seniornějších lidí na možná řešení různých problémů. Reakce většinou začínala něčím jako: "Noo, já bych se asi nejdřív zeptal Billa, co by s tím dělal. Ale když už tu Bill není..tak nevím". A tak jsem se naučil dělat rozhodnutí. Byla to sranda, občas jsem měl chuť si prostě hodit korunou, ale nakonec jsem se (většinou) stejně dobral závěru otravováním dostatečného počtu lidí, z jejichž odborných protichůdných názorů jsem vydestiloval něco užitečného a potenciálně smysluplného.

Pak přišel Docker a náš tým dostal za úkol připravit RHELové a Fedoří image (tj. co nejmenší verze zmíněných operačních systémů, které poběží jako linuxové kontejnery). Už ani nevím, jak jsem se k tomu dostal, ale myslím, že potřebovali, aby na to kouknul "architekt" a že na základě diskuze, že nikdo nemá čas, jsem nakonec souhlasil, že to udělám. A tak začala cool jízda, kdy jsem se vrtal v Dockeru a začal produkovat nějaké artefakty, které se začaly dodávat zákazníkům. Dlužno říct, že to možná přistálo u mě taky proto, že už jsem předtím projevil slušnou míru pochopení procesů v release engineeringu, což je něco jako chápat, kde se berou jednorožci a kam chodí spát víly.


Nejlepší na tom všem bylo, že jsem v podstatě asi každý týden řešil něco úplně jiného. Na všechno jsem psal skripty, naučil jsem se Python a napsal v něm pár věcí, které se pak ještě chvíli používaly, ale všichni mě za to ještě o rok později nenávidí. (Už jsem říkal, že nejsem dobrý programátor?) No ale hlavně jsem začal chodit na spousty meetingů a poznávat spoustu zajímavých lidí. Jo a na chvilku jsem se zbavil Bugzilly! Ale jen na chvilku, protože když jsme se přehoupli přes tu fázi "pojďme pánové, budeme si hrát s Dockerem" do fáze, "milý zákazníku, zde jsou tvé aktuální, bezpečné a oficiální image", zase mě ta mrcha dohnala.

A taky přišlo cestování. Když děláte na Dockeru, jste cool. Když jste cool, lidi s vámi chtějí mluvit. Když s vámi chtějí lidi mluvit, chtějí, abyste se ukázali v Americe. A tak jsem jel v září 2014 poprvé do USA do Westfordu na nějaký šílený meeting. Asi to dopadlo dobře, protože jsem pak hned v prosinci jel na konferenci DockerCon. A v březnu zase do Ameriky.

V březnu v Americe jsem se potkal s pár lidmi, které už jsem zběžně znal, ale taky s pár novými lidmi. Musím podotknout, že to byla velmi vybraná společnost. Ultra-chytří a mega-zkušení jedinci. Pustili jsme se do vymýšlení něčeho nového (později jsme to nazvali Nulecule). Asi jsme nevymysleli úplnou blbost, protože za měsíc jsem jel do USA znovu. A pak za měsíc zase. Sranda.

Ohlédnutí zpět do roku 2012 "Ach joo, já ten grub nechápu. Asi se mrknu po nějakém jiném místě, protože tohle nejde. Šel bych pracovat někam do ciziny." Přesun do jara 2015: "Hmm, mám všechno? Jak člověk furt někam lítá, tak přestane být nervozní a začne zapomínat věci..."

No a dnes (v pondělí) zase letím do Westfordu (dozvěděl jsem se to ve středu...). A je to sranda. Mám rád tyhle nárazovky. Krásně to rozbíjí stereotyp. Ačkoliv, jaký stereotyp? Co vlastně dělám teď? Úplně cokoliv. Od nudné práce package maintainera jsem se díky okolnostem, všímavosti ostatních lidí a asi trochu i schopnostem a drzosti, dostal k práci, která mě nutí se denně něco nového učit, pracovat napříč mnoha týmy, přinesla mi přátele po celém světě, umožnila mi cestovat, vybírat si, na které konference se pojedu podívat. Můžu "kódit", když mám chuť, dělat projektového manažera, pomáhat lidem s rozvojem, propagovat jejich práci tam, kam se oni třeba nedostanou.

Co jsem se vlastně tímhle postem snažil říct? Asi to, že Red Hat je místo netušených možností. Asi, že jsem šťastný. Asi se taky trochu pochlubit a motivovat kohokoliv, kdo tenhle kus textu přečetl, že i když to na začátku vypadá všelijak, je potřeba se nevzdat a chytnout se příležitosti, která se nabízí. Takže držím palce, ať vám to taky klapne.

A Radku, díky, že jsi mě vytáhl od grubu a udělal ze mě mini-Billa:).

Moje cesta k Red Hatu

Když jsem chodil na střední, dělal jsem webovky - asi jako (skoro) všichni začínající IT nadšenci. Když jsem se rozhodl, že půjdu na FIT VUT, trochu jsem se děsil, protože, inu, dělal jsem webovky, trochu Pascalu, ale hlavně webovky - v PHP... Na FITu přece frčí v Cčku, Javě, Assembleru a dalších obskurních jazycích, které moje nezkušené IT očko do té doby nespatřilo.

Ok, jdeme dál, dostal jsem se na FIT a zjistil, že Cčko, je docela cool, i když mi zabralo pár projektů, než jsem pochopil pointry. Assembler je maso, ale když v něm jednou napíšete hada (sakra, musím ten kód najít), je to hračka. Javu pořád nesnáším (hej, vy, headhunteři, co mi náhodně píšete, ať jdu dělat Javu do nějaké banky: "Ani za nic!"). No, každopádně, na FITu jsem se naučil trochu programovat, ale musím se přiznat, že když byl týmový projekt, první jsem se hlásil na psaní dokumentace a prezentaci. Pak jsem dobastlil zbytky, do kterých se nikomu nechtělo. Už na FITu mi bylo jasné, že famózní programátor ze mě nikdy nebude a že bych asi chtěl dělat projektového manažera, nebo prostě jen manažera. Jo a celou dobu jsem dělal webovky!

V posledním ročníku jsem už PHPčka měl plné zuby, takže jsem odpověděl na inzerát v novinách, kde hledali programátora. Šel jsem na pohovor, vysvětlil, že o Windowsech vím houby, v C# jsem nikdy nedělal, MSSQL bych se snad radši vyhnul a že moje bakalářka byla neskutečně cool záležitost. Kupodivu mě vzali, takže jsem se v rámci brigády v Anglii pustil do čtení knihy o .NETu a C# (myslím, že jsem přečetl první kapitolu a přestalo mě to bavit). Takže jsem nastoupil do práce, kde jsem dostal na starost mini projektík a pustil jsem se do kódění v jazyce, o které jsem nic nevěděl. Zabralo mi asi měsíc se do toho dostat, ale pak to šlo jako po másle - C# je rozhodně nejlepší jazyk, ve kterém jsem kdy psal.

Byla to parádní práce, firma Elsyst, kde jsem pracoval, se zabývá (mimo jiné) digitalizací dokumentů, a když jsem pro ně pracoval, digitalizovali jsme zrovna Národní knihovnu. Bylo to super. Do chvíle, kdy si někdo vzpomněl, že jsem dělal webovky, takže bych mohl udělat webový informační systém. Jako zelenáč jsem to odkýval, protože mě ani nenapadlo, že bych mohl svému chlebodárci říct ne. Pustil jsem se do toho, udělal prezentaci první verze pro hlavouny z Národní knihovny a Karlovy univerzity a všichni byli nadšení a spokojení. Všichni až na mě...já dělal..webovky..zase.

V té době jeden z mých vysokoškolských spolužáků už skoro rok pracoval v Red Hatu. Vychvaloval to tak moc, že mě to taky začalo lákat. Inu, kouknul jsem na pozice a nechal se doporučit. Můj pohovor probíhal chaoticky, detailně a asi 3 hodiny. Výsledkem bylo, že jsem po státnicích a 14 dnech "volna", které jsem strávil psaním dokumentace k projektům v Elsystu, nastoupil do úplně nejvíc nejlepší firmy, jakou jsem si do té doby dovedl představit.


No a co, že jsem musel začít jezdit do práce do Brna místo toho, abych se jen 15 minut prošel. No a co, že jsem měl na plný úvazek menší plat, než na poloviční v Elsystu. No a co, že jsem vůbec nevěděl, co tam budu dělat a jestli mi to půjde. Hlavně, že jsem se mohl zbavit těch fujky Windowsů a začít pracovat na Linuxu v Red Hatu!

Pokračování příště...

Kubernetes Persistent Storage Hell

We've started to work on a rather complex application recently with my team at Red Hat. We all agreed it'll be best to use containers, Kubernetes and Vagrant to make our development (and testing) environment easy to setup (and to be cool, obviously).

Our application consists of multiple components where those important for the post are MongoDB and something we can call worker. The reason for MongoDB is clear - we are working with JSONs and need to store them somewhere. Worker takes data, does some works on them and writes to DB. There are multiple types of workers and they need to share some data. We also need to be able to scale (That's why we use containers!) which also requires shared storage. We want both storages to be local path (for Vagrant use case especially).

Sounds easy, right? But it's not. Here is the config objects situation:


The way you work with volumes i Kubernetes is that you define a PersistentVolume object stating capacity, access mode and host path (still talking about local storage). Then you define PersistentVolumeClaim with access mode and capacity. Kubernetes then automagically map these two - i.e. randomly match claim and volume where volume provides correct mode and enough capacity.

You might be able to see the problem now, but if not, here it is: If you have 2 volumes and 2 claims (as we have) there is no way you can be sure which claim will get which volume. You might not care when you first start your app, because the directories you provided for volumes will be probably empty. But what if you restart the app? Or the Vagrant box (and thus the app)? You cannot be sure which volume will be assigned to which claim.

This leads to an inconsistent state where your MongoDB storage can be assigned to your worker storage and vice versa.

I've found 2 related issues on github and which, if implemented and solved, should fix it. But is there a workaround?

Hell yeah! And it's pretty simple. Instead of defining PersistentVolumeClaim object and using persistentVolumeClaim key in a replication controller, you can use hostPath directly in the RC. This is how the patch looked like:

diff --git a/kubernetes/mongodb-controller.yaml b/kubernetes/mongodb-controller.yaml
index ffdd5f3..9d7bbe2 100644
--- a/kubernetes/mongodb-controller.yaml
+++ b/kubernetes/mongodb-controller.yaml
@@ -23,5 +23,5 @@ spec:
 mountPath: /data/db
 - name: mongo-persistent-storage
- persistentVolumeClaim:
- claimName: myclaim-1
+ hostPath:
+ path: "/media/mongo-data"
diff --git a/kubernetes/worker-controller.yaml b/kubernetes/worker-controller.yaml
index 51181df..f62df47 100644
--- a/kubernetes/worker-controller.yaml
+++ b/kubernetes/worker-controller.yaml
@@ -44,5 +44,6 @@ spec:
 mountPath: /data
 - name: worker-persistent-storage
- persistentVolumeClaim:
- claimName: myclaim-2
+ hostPath:
+ path: "/media/worker-data"

The important bits of Kubernetes config then looks like:

     - name: mongo-persistent-storage
       mountPath: /data/db
   - name: mongo-persistent-storage
       path: "/media/mongo-data"

Mapping service ports to nodes in Kubernetes

Kubernetes is a great project and cool/hot technology. Although it made me to hate JSON (and YAML), I still enjoy exploring the possibilities it brings to your applications deployment.

It's also a base for even more awesome project called OpenShift (*cough* shameless plug included *cough*).

Anyway, I ran into a problem where I needed to expose port(s) of my application to the outer world (i.e. from Vagrant box to my host) and I struggled to find the solution quickly.

Normally, when you are on the machine where Kubes run, you will do something like this

[[email protected] ~]$ kubectl get services | grep flower
flower-service component=flower app=taskQueue,component=flower 5555/TCP

IOW I just listed all running services and grepped for flower. I can take IP and port from there now and use curl to get contents provided by that service. This uses the Kubernetes virtual network to get to the endpoint.

I can also do this

[[email protected] ~]$ kubectl get endpoints | grep flower

which gets me directly to container IP and port.

But this all happens in my Vagrant box (as you can see from the CLI prompt). This setup is good for places like Google Cloud or AWS where you get load balancing and port forwarding for free. But what if I just want to access my app on the VM IP address?

Well, you take your Kubernetes service config/artefact/JSON/YAML and modify it a bit. By default, Kubernetes services are set to "ClusterIP" mode where they are accessible only by the ways showed above. You'll want to change the type to "NodePort".

This will "use a cluster IP, but also expose the service on a port on each node of the cluster (the same port on each node)" according to docs.

apiVersion: v1
 kind: Service
     component: flower
     name: flower-service
  type: NodePort
    - port: 5555
      nodePort: 31000
    app: taskQueue
    component: flower

By default, type NodePort will give you a random port in a range 30000-32767. You can also pick a specific port from this range (as you can see above). Well, that's it. You only need to know the IP of the machine and the given/specified port.

[[email protected] vagrant]$ kubectl describe service flower-service | grep "^NodePort"
NodePort: <unnamed> 31000/TCP

This is particularly useful when you are developing (with VM, as the use case described above), or if you have some testing instance in the cloud (where the load balancers are not available) and want to expose the app easily without having to fiddle with too many other pieces.

What the hell does Nulecule try to solve?

There are some statements on the Project Atomic website about Nulecule. There is also some information in the Nulecule Github repository. I've spent big portion of DockerCon explaining Nulecule to various people and here is what my explanation boiled down to:

1. Parameterization

As a deployer of multi-container application, I want to have simple way how to parameterize orchestration manifests

  •  f.e. if you look at kubernetes/examples, you can see "change this, and that in the JSON configs to make this app working in your environment" in every other example.

2. Reusability

As a developer of a multi-container application I want to use existing components (like databases) in my application so that I don't have to burn my time on something that already exists.

  • f.e. as someone creating a voting app (borrowing from DockerCon:) ) I want to use Redis and Postgresql components and only add frontend and worker to the equation.

3. Multiple Orchestrations - providers

As a developer of a multi-container application I want enable deployment to multiple orchestration providers for my application so that users can easily migrate.

4. Distribution

As an enterprise consumer of a multi-container application I want to avoid any out-of-band transport layer for the application and it's metadata

  • f.e. I use Docker images and have a private registry set up. Instead of having to setup another authenticated webserver and figure out how to verify what I pull as tarballs or plain text, I will package every piece of puzzle into a Docker image and distribute it through registry.

The next and very valid question is: "How well did we tackled down these challenges?" That's up to you to figure out and tell us and ideally help us fix bits that you struggle with.