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, no..co 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).

IMG_20140429_122613

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.

IMG_20131105_095420

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.

DSCF4339

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:

kubernetes/worker-volume.yaml
kubernetes/worker-claim.yaml
kubernetes/mongo-volume.yaml
kubernetes/mongo-claim.yaml

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 https://github.com/.../issues/14908 and https://github.com/.../pull/17056 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
 volumes:
 - 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
 volumes:
 - name: worker-persistent-storage
- persistentVolumeClaim:
- claimName: myclaim-2
+ hostPath:
+ path: "/media/worker-data"

The important bits of Kubernetes config then looks like:

...
   volumeMounts:
     - name: mongo-persistent-storage
       mountPath: /data/db
 volumes:
   - name: mongo-persistent-storage
     hostPath:
       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

[vagrant@centos7-adb ~]$ kubectl get services | grep flower
flower-service component=flower app=taskQueue,component=flower 10.254.126.210 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

[vagrant@centos7-adb ~]$ kubectl get endpoints | grep flower
flower-service 172.17.0.7:5555

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
 metadata:
   labels:
     component: flower
     name: flower-service
spec:
  type: NodePort
  ports:
    - port: 5555
      nodePort: 31000
  selector:
    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.

[vagrant@centos7-adb 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.

DockerCon Europe 2015 (and conferences in general)

As some of you (those following me on various social networks) may know, I attended DockerCon EU 2015 in Barcelona. When I think about how to describe how I feel when it's finished, few words come to my mind, so let's list them and go deeper.

1. Sad

I feel sad DockerCon took only 2 days. That's not enough time to meet all the smart people there. It's not enough time to learn about all the cool projects these people brought there. It's not enough time to do the previous two and still attend sessions and talks to learn about what organizers considered the most interesting topics from (I guess) giant pool of submissions.

On the other hand, it's a great opportunity to try to stay in touch with all the people and learn about them and their projects in coming weeks.

2. Motivated

Conferences always motivate me to learn more, try more, work harder, be better - be as good or better then those people presenting their projects and ideas. I am also the most productive during the few weeks after the conference as I can still feel the connection with the community and I can "replay" the discussions I had with much smarter and much more experienced people.

3. Inspired

There is so much inspiration around on conferences! We as engineers need inspiration to build better solutions, create new ways how things can work, figure out new connections between existing pieces. There are many ways how to find an inspiration but for me conferences and meeting new people works best and this year DockerCon was extremely rich in this.

4. Open-minded

Funny thing about day-to-day work that one slowly slides down to stereotypes - both, in doing and thinking. Although you might not realize, it's inevitable - unless you are Elon Musk, Mark Zuckerberg...or any other visionary:). Anyway, events like conferences or good meetups keep me upbeat and give me different points of view on things I am doing (and make me think if I should just trash many of them;) )

5. Limitless

Talking to smart people, watching talks (live, I don't feel the same when I watch a video), coming up with ideas regarding others' projects is like good drug - you feel strong, you feel like you can jump on anything at you will make it work. My had is full of ideas after conferences like DockerCon and my only concern is that there is not enough time to try them all:).

Anyway, as you could see, I really enjoyed the event. Many thanks to organizes and to attendees for a great atmosphere and of course thanks to Red Hat who paid for my travels and ticket. Amazing place to be - both, the conference and Red Hat!

Fedora Developer Portal – how to contribute

The great thing about working at Red Hat is being part of the Fedora community and as a part of this group of enthusiastic people you get close to cool, interesting, awesome, innovative, important... projects. And you get close to them while they are at the beginning and you can influence where they go.

One of those projects is Fedora Developer Portal which will help developers to start their projects on Fedora. It will help you figure out what languages, frameworks, or databases are available in our distribution. How to use Docker, Vagrant or Copr build system to package, distribute and deploy your projects. There is already content ready for you to help you with setting things up for Arduino. Much of other content is in preparations and even more is waiting for you to come and join the project!

My contribution to the project so far has been making it easy for you to contribute. I helped guys with contribution guidelines and I created a Docker image which will let you run the website locally so that you can review your contributions.

This is what you can also find in a README.md for the website project:

$ sudo docker run -it --rm developerportal/devel
[sudo] password for vpavlin: 
Previous HEAD position was 702f2a3... move logo to static directory
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
Already up-to-date.
Configuration file: /opt/developerportal/website/_config.yml
/home/dp/.gem/ruby/gems/jekyll-lunr-js-search-0.3.0/lib/jekyll_lunr_js_search/version.rb:3: warning: already initialized constant Jekyll::LunrJsSearch::VERSION
/opt/developerportal/website/_plugins/jekyll_lunr_js_search.rb:245: warning: previous definition of VERSION was here
 Source: /opt/developerportal/website
 Destination: /opt/developerportal/website/_site
 Generating... 
 Lunr: Creating search index...
 Build Warning: Layout 'page' requested in content/fedora_features/Fedora23_Self_contained_Changes.md does not exist.
 Build Warning: Layout 'page' requested in content/fedora_features/Fedora23_System_Wide_Changes.md does not exist.
...
 Lunr: Index ready (lunr.js v0.4.5)
 done.
 Auto-regeneration: enabled for '/opt/developerportal/website'
Configuration file: /opt/developerportal/website/_config.yml
 Server address: http://172.17.0.5:8080/
 Server running... press ctrl-c to stop.

You can see a server address - that's what you need to copy to your browser to view the page.

Screenshot from 2015-09-02 09-39-51

Now you have the local dev instance running. What if you want to display your changes? First, you clone the content repository.

$ git clone https://github.com/developer-portal/content

Then you will have to modify the run command a bit - specifically, add a volume mount (replace $PWD/content with the path to the cloned content repository):

$ sudo docker run -it --rm -v $PWD/content:/opt/developerportal/website/content developerportal/devel

Ok, now what if you don't want to contribute to content of the portal but rather to help guys making the website awesome? The approach is the same as above. First, you clone the website repository.

$ git clone https://github.com/developer-portal/website

Then you run the container just with the mount for website instead of content.

$ sudo docker run -it --rm -v $PWD/website:/opt/developerportal/website developerportal/devel

Jekyll is used to render the website and it's content and it's set up in the way that whenever you edit any file the website re-renders itself and you can simply refresh the browser when it's finished.

The rest is easy - you change whatever you want, push to your fork on Github, submit a pull request. Once it's reviewed, your changes will appear on the web. Yay!

Ok, my job is done here. Now it's your turn to contribute and promote it further!:)

How to (be a) man on Atomic Host

One major thing missing on the Atomic Host are manual pages. Not a terrible thing - you can always google for them, right? But what if you cannot? Then there is the Fedora Tools Docker image. Try this:

-bash-4.3$ alias man="sudo atomic run vpavlin/fedora-tools man"
-bash-4.3$ man systemd

You should see a manual page for systemd. Thinking about it, that's it. Nothing more you need to now about it. Simple:)