DNS Server Master/Slave tramite Ansible

Devo mettere in piedi un DNS server master/slave e mi trovo davanti al solito quesito sulle opzioni per l’implementazione. Come lo faccio?

  1. a manina
  2. Chef
  3. Ansible

L’opzione numero uno (ogni tanto e soprattutto per i miei ambienti di laboratorio) inizia a sembrarmi quella più rapida, ma per tenersi allenati su IaC è bene usare la 2 o la 3.

Siccome il DNS mi serve per un cluster Openshift direi di procedere con la 3, così farò tutto con Ansible.

1_hdwjXl1x4Q3VXmL7UG1XrQ

Ho preso in affitto una macchina fisica su Kimsufi con sopra Proxmox come hypervisor.

Screen Shot 2018-07-15 at 11.27.50

La rete è configurata così.

ocmaster39 (eth0: 10.10.10.10/24, eth1: 192.168.56.10/16)

ocslave39 (eth0: 10.10.10.11/24, eth1: 192.168.56.11/16)

Il nostro DNS ascolterà sulla 192.168.0.0 mentre sulla 10.10.10.0 attesterò i servizi di OC.

Una volta completato l’inventory file che è veramente molto scarno in questo caso eseguirò i playbook.

[dns_master]
192.168.56.10 ansible_connection=local

[dns_slave]
192.168.56.11



Eseguiamo qualche comando per vedere che la comunicazione funzioni…

[root@ocmaster39 ansible-role-bind]# ansible all -a 'whoami' -m shell
192.168.56.10 | SUCCESS | rc=0 >>
root

192.168.56.11 | SUCCESS | rc=0 >>
root

Ok si.. tutti usano il ping e quindi lo userò anche io,

[root@ocmaster39 ansible-role-bind]# ansible all -m ping
192.168.56.10 | SUCCESS => {
"changed": false,
"failed": false,
"ping": "pong"
}
192.168.56.11 | SUCCESS => {
"changed": false,
"failed": false,
"ping": "pong"
}

Convergenza del master (sotto è riportato il playbook usato)

ansible-playbook master.yml

Convergenza slave

ansible-playbook slave.yml

A questo punto Bind è installato e configurato, per cui interroghiamo il master…

[root@ocmaster39 ~]# dig @192.168.56.10 google.it | grep -n1 "ANSWER SECTION"
13-
14:;; ANSWER SECTION:
15-google.it. 188 IN A 172.217.18.195
[root@ocmaster39 ~]# dig @192.168.56.10 ocslave39.openshift.local | grep -n1 "ANSWER SECTION"
13-
14:;; ANSWER SECTION:
15-ocslave39.openshift.local. 1209600 IN A 192.168.56.11

… ora lo slave …

[root@ocmaster39 ~]# dig @192.168.56.11 ocslave39.openshift.local | grep -n1 "ANSWER SECTION"
13-
14:;; ANSWER SECTION:
15-ocslave39.openshift.local. 1209600 IN A 192.168.56.11

Ho forkato il playbook originale per una PR dove ho aggiunto i playbook usati e un po’ di doc.

Trovate l’esempio usato qui

Ciao!

Come dare fastidio a chi ascolta la radio in spiaggia ( a volume molto alto ) e interrompe il vostro momento zen

Un saluto estivo a tutti i lettori di devopsrecipes.info 😉

Le mie vacanze si avvicinano e presto potrò finalmente allontanarmi dal caos cittadino… Nel mio zaino, oltre ad set di birre ricercatissime ( una paio di Peroni da 66 ) quest’anno ci sarà anche un trasmettitore radio FM pirata, nel caso qualcuno disturbi il mio sonno sentendo la radio ad alto volume… Se vi siete drogati, è molto probabile che la musica che sentite non è trasmessa da alcun vicino, per cui andate a prendervi un Calippo.

listening-to-old-time-radio-on-the-beach

Procuratevi più o meno le seguenti cose, oppure compratevi un trasmettitore radio su Amazon ( però sappiate che è poco fico comprarlo già fatto o scaricare app )

  1. Un Raspberry PI
  2. Un alimentatore portatile per smartphone ( meglio se ad energia solare)
  3. Una pennetta wireless
  4. Uno script in php per la gestione tramite interfaccia web (https://github.com/lucky-sideburn/piratepiwave.git)
  5. Il software https://github.com/rm-hull/pifm per l’erogazione del segnale FM
  6. Il…

View original post 203 more words

Docker images pruning with Openshift Origin

openshift-card

In order to test the Docker images pruning with Openshift Origin I made the following test.

Environment:

  • Two nodes, one master + infra and a workload node.
  • Cluster version: Openshift Origin 3.6

First of all I have built a Docker image based on NodeJS within a large file. The file.out is of 50M and after compression it decreases little.

Structure of my NodeJS app

[root@origin-master nodeapp]# ls -lhas

total 51M

 0 drwxr-xr-x. 2 root root 106 May 27 16:41 .

 0 drwx------. 6 vagrant vagrant 228 May 27 09:09 ..

4.0K -rw-r--r--. 1 root root 136 May 27 16:22 Dockerfile

4.0K -rw-r--r--. 1 root root 261 May 27 16:18 create_fake_images.sh

 50M -rw-r--r--. 1 root root 50M May 27 16:18 file.out

4.0K -rw-r--r--. 1 root root 265 May 27 09:09 package.json

4.0K -rw-r--r--. 1 root root 539 May 27 15:19 server.js

The Dockerfile is very simple!

[root@origin-master nodeapp]# cat Dockerfile

FROM node

# Create app directory

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 8080

CMD [ "npm", "start" ]

The following script helped me to generate many images with additional and differents layers. Each iterations copy the 50M file inside the image.

for i in $(seq 1 1000)

do

 echo "RUN echo $i" >> Dockerfile

 echo "COPY file.out ./$i.out" >> Dockerfile

 docker build -t docker-registry-default.origin.local/test/nodeapp:latest .

 docker push docker-registry-default.origin.local/test/nodeapp:latest

done

Let's see how the Docker registry folder increase size during create_fake_images.sh execution.

1a4c7633d886: Pushing [=======> ] 8.325 MB/52.43 MB

e36035decad2: Pushing [=======> ] 7.768 MB/52.43 MB

bb1e26b5f124: Pushing [=======> ] 7.768 MB/52.43 MB

13c3d2712668: Pushing [===========> ] 11.67 MB/52.43 MB

dbc4876ab96c: Pushing [=======> ] 8.327 MB/52.43 MB

[root@origin-master vagrant]# du -chs /data/origin/

 782M /data/origin/

 782M total

[root@origin-master vagrant]# du -chs /data/origin/

 956M /data/origin/

 956M total

[root@origin-master vagrant]# du -chs /data/origin/

 1.2G /data/origin/

 1.2G total

Describing image stream nodeapp we can see the latest images pushed to the registry

[root@origin-master nodeapp]# oc describe is

Name: nodeapp

Namespace: test

Created: 2 hours ago

Labels: <none>

Annotations: <none>

Docker Pull Spec: docker-registry.default.svc:5000/test/nodeapp

Image Lookup: local=false

Unique Images: 5

Tags: 1

latest

 pushed image

* docker-registry.default.svc:5000/test/nodeapp@sha256:6f517f2bd667280587daebd57c456c723df4e97d72903100cad441821203e4ec

 22 seconds ago

 docker-registry.default.svc:5000/test/nodeapp@sha256:421155780252a908de9c4968c65a508c65b12b259a6248278b73dd20edee20fb

 About a minute ago

 docker-registry.default.svc:5000/test/nodeapp@sha256:b26f1d2cac95a73632891a6cfec875baed0b1a4165c381e59e0ce4d1bfc403f9

 About a minute ago

 docker-registry.default.svc:5000/test/nodeapp@sha256:6d6f63093aae64198fb1d7af2cd2a361cec991817c8e6944910cb84420a52c1b

 20 minutes ago

 docker-registry.default.svc:5000/test/nodeapp@sha256:6e82ae61a154788ff70ff3ed69cf3a088845e0c7c2d1441de4123c213a0f0116

 23 minutes ago

I changed the Dockerfile in order to have an image that does not import large file. So I have built and pushed the following Docker image

[root@origin-master nodeapp]# cat Dockerfile

FROM node

# Create app directory

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 8080

CMD [ "npm", "start" ]

Let’s start to prune

tree-pruning1

  1. Delete old deployments
[root@origin-master nodeapp]# oc adm prune deployments --orphans --keep-complete=1 --keep-failed=1 --keep-younger-than=1m

Dry run enabled - no modifications will be made. Add --confirm to remove deployments

NAMESPACE NAME

test nodeapp2-23

test nodeapp2-22

test nodeapp2-21

test nodeapp2-20
  1. Prune the unused images and keep only one revision
[root@origin-master nodeapp]# oc adm prune images --keep-tag-revisions=1 --keep-younger-than=1m --confirm

Deleting references from image streams to images ...

STREAM IMAGE TAGS

test/nodeapp sha256:6e82ae61a154788ff70ff3ed69cf3a088845e0c7c2d1441de4123c213a0f0116 latest

test/nodeapp sha256:421155780252a908de9c4968c65a508c65b12b259a6248278b73dd20edee20fb latest

test/nodeapp sha256:b26f1d2cac95a73632891a6cfec875baed0b1a4165c381e59e0ce4d1bfc403f9 latest

Deleting registry repository layer links ...

REPO LAYER LINK

test/nodeapp sha256:3de138bf364bf3e2684c78468d07a0e2ca786ba08f83bd1b7e3373a1e0b407e5

test/nodeapp sha256:a75ed4d808fc563081de632debf91580a6dbe6d694971ca6888b5be4433f55cc

test/nodeapp sha256:677e3bfb00ad311212b46be4ddb20f5b762765fef676c6d4a85e5dbcb943c4a4

test/nodeapp sha256:29510362ff8e174edf88563f6099141b9e82efd5cd48b14aeaa74fea532e6d43

test/nodeapp sha256:35dc109c74dfcab9f1f027ccc1404e7ef3f524d6efea226e3920959051819f2c

test/nodeapp sha256:f3d40164b23c42356d717da92b91774402632a8df22cd5ddfb7926fc3a7292f6

test/nodeapp sha256:fe03b24c2c84648d09331dbd72a8065b8ed550be991155edc72ad1166f1ef666

test/nodeapp sha256:8eaf1a821a6b8a2e325cebce83311c5d3b33427140d84954f504ed59bab51109

test/nodeapp sha256:684c30e67a270d2115cb4be1c9712193bf0b4393ffa04b3c625e76fadd6bda12

test/nodeapp sha256:7d6ad63a8e94a938a95fa1e27106bbc7ecfa3680b3ff3a11c7bdb43ae610eb18

test/nodeapp sha256:e1614bf81372b99eb86c74ac9c023c01077061db81c4daeaf6683e27299e48cc

test/nodeapp sha256:a92bff6ede96a89a94fe2ca794115e1c374312d05e895698e6b1638c3b647645

test/nodeapp sha256:2d9ccccdee639671c6cb24110e529b738535453a3ccdf68989ac31ea6894929d

test/nodeapp sha256:1e920f3f2676bc50c60a95c9d8710cb91429ab07278616c02680b0f38af2d224

test/nodeapp sha256:90b58c4583c3de52b6f6762c83a02d42dd18747a2541bafb483a9cdbc5e55f8b

test/nodeapp sha256:d041de45e8895ee77b4e6ba112959e361d888b5694910b44f54fb88f0ef3fb4f

Deleting registry layer blobs ...

BLOB

sha256:3de138bf364bf3e2684c78468d07a0e2ca786ba08f83bd1b7e3373a1e0b407e5

sha256:a75ed4d808fc563081de632debf91580a6dbe6d694971ca6888b5be4433f55cc

sha256:677e3bfb00ad311212b46be4ddb20f5b762765fef676c6d4a85e5dbcb943c4a4

sha256:29510362ff8e174edf88563f6099141b9e82efd5cd48b14aeaa74fea532e6d43

sha256:35dc109c74dfcab9f1f027ccc1404e7ef3f524d6efea226e3920959051819f2c

sha256:f3d40164b23c42356d717da92b91774402632a8df22cd5ddfb7926fc3a7292f6

sha256:fe03b24c2c84648d09331dbd72a8065b8ed550be991155edc72ad1166f1ef666

sha256:8eaf1a821a6b8a2e325cebce83311c5d3b33427140d84954f504ed59bab51109

sha256:684c30e67a270d2115cb4be1c9712193bf0b4393ffa04b3c625e76fadd6bda12

sha256:7d6ad63a8e94a938a95fa1e27106bbc7ecfa3680b3ff3a11c7bdb43ae610eb18

sha256:e1614bf81372b99eb86c74ac9c023c01077061db81c4daeaf6683e27299e48cc

sha256:a92bff6ede96a89a94fe2ca794115e1c374312d05e895698e6b1638c3b647645

sha256:2d9ccccdee639671c6cb24110e529b738535453a3ccdf68989ac31ea6894929d

sha256:1e920f3f2676bc50c60a95c9d8710cb91429ab07278616c02680b0f38af2d224

sha256:90b58c4583c3de52b6f6762c83a02d42dd18747a2541bafb483a9cdbc5e55f8b

sha256:d041de45e8895ee77b4e6ba112959e361d888b5694910b44f54fb88f0ef3fb4f

Deleting registry repository manifest data ...

REPO IMAGE

test/nodeapp sha256:6e82ae61a154788ff70ff3ed69cf3a088845e0c7c2d1441de4123c213a0f0116

test/nodeapp sha256:421155780252a908de9c4968c65a508c65b12b259a6248278b73dd20edee20fb

test/nodeapp sha256:b26f1d2cac95a73632891a6cfec875baed0b1a4165c381e59e0ce4d1bfc403f9

Deleting images from server ...

IMAGE

sha256:6e82ae61a154788ff70ff3ed69cf3a088845e0c7c2d1441de4123c213a0f0116

sha256:421155780252a908de9c4968c65a508c65b12b259a6248278b73dd20edee20fb

sha256:b26f1d2cac95a73632891a6cfec875baed0b1a4165c381e59e0ce4d1bfc403f9

Check the size of  registry folder

[root@origin-master nodeapp]# du -chs /data/origin/
608M /data/origin/
608M total

Ok from 1.6gb we went down to 608M !

Provisioning di grandi monoliti con Vagrant

Il post di oggi vorrei usarlo per tenere traccia di alcune metodologie che sto usando per il provisioning di stack pesanti e che richiedono tempi lunghissimi.

Il software interessato rientra nella categoria del “monolite”. Lo stack monolitico è una sorta di amico enorme e per portarlo in giro bisogna prendere determinate precauzioni.

È tipo Zangief…

hqdefault

Per il raggiungimento del risultato finale, ovvero il bootstrap di ambienti completi, sto implementando un giro di provisioning fatto da cookbook Chef, script shell e Rubygem custom.

Alcuni ostacoli del progetto:

  1. Per un provisioning completo ci vogliono più di 3 ore
  2. La fase di installazione e configurazione è composta da centinaia di esecuzioni di script, chiamate a servizi REST e numerosi riavvii di servizi systemd. Tutto deve essere rigorosamente idempotente.
  3. Gli errori durante il provisioning sono da evitare assolutamente. Ripartire nel mezzo dell’installazione non è mai come partire da zero.

La scelta del provisioner e per cosa usarlo

Di base, a meno che non ci siano vincoli progettuali, siamo in grado di fare quasi tutto con i più importanti configuration management tool come Chef, Puppet e Ansible.

È importante capire cosa far fare al provisioner e cosa no. Alcune operazioni che sono specifiche per il mio ambiente di laboratorio le metto tranquillamente in blocchi shell script (che alla fine è anch’esso un provisioner di Vagrant)

 
 $script = <<-SCRIPT echo I am provisioning... date > /etc/vagrant_provisioned_at
 SCRIPT

Vagrant.configure("2") do |config|
 config.vm.provision "shell", inline: $script
 end

Per usare o meno un proxy può essere utile una semplice variabile d’ambiente.

if ENV['NO_CUSTOMER_PROXY']
 config.vm.provision 'shell',
 inline: '> /etc/profile.d/proxy.sh'
 config.vm.provision 'shell',
 inline: '> /etc/environment'
 else
 config.proxy.http = 'http://CUSTOMER.PROXY.LOCAL:8080'
 config.proxy.https = 'http://CUSTOMER.PROXY.LOCAL:8080'
 config.proxy.no_proxy = ''
 end

 

Roadmap delle box

Il punto è che non vogliamo fare e rifare il lunghissimo provisioning tutte le volte ma poter “debuggare” stati diversi della macchina.
Per esempio, nel caso esistano i seguenti possibili stati:

  1. macchina con prerequisiti installati, aggiornamenti OS e personalizzazioni.
  2. macchina con monolite installato.
  3. macchina con monolite configurato.
  4. macchina con applicazioni del monolite configurate.

Rifare tutto da zero può richiedere parecchio tempo per cui ho utilizzato il “package” di Vagrant…

vagrant package --base $id --output os_ok.box; vagrant box os_ok.box
vagrant package --base $id --output monolite_ok.box; vagrant box add monolite_ok.box
vagrant package --base $id --output monolite_configurato.box; vagrant box monolite_configurato.box
vagrant package --base $id --output monolite_con_applicazioni_configurate.box; vagrant box add monolite_con_applicazioni_configurate.box

All’occorrenza, nel Vagrantfile e nel bocco relativo alla vm, ho usato la box che mi serviva in determinato punto.

Archivi pesanti in /vagrant

Durante il provisioning ho avuto bisogno di scaricare da locazioni remote archivi anche di grandi dimensioni.

Questo durante le prove  non è performante per cui i puntamenti, dei ruoli Chef nel mio caso,  sono tutti verso src: “file:////vagrant/foo.tar.gz”. Naturalmente è opportuno dichiararli nel .gitignore.

Ciao

il mio ultimo libro…

Nel tempo libero ho iniziato a scrivere libri e uno di questi ho pensato di pubblicarlo…

Il protagonista di Skynet (così ho chiamato il libro) è un giovane hacker romano che si troverà a dover combattere un potere occulto che cerca di danneggiare Roma fin dai tempi della sua fondazione.

Si troverà faccia a faccia con le temibili sorelle della Toga Nigra, ovvero delle combattenti molto arrabbiate per il Ratto delle Sabine e che negli anni sono diventate le attuali suore.

Si, il racconto parla di suore hacker e combattimenti alla Matrix.

Ho optato per alcuni luoghi di internet dove condividere il libro

  1. su Github
  2. come ebook su Amazon
  3. come pdf

68190-skynet-il-perche-a-roma-non-funzionano-le-cose

Saluti!

DevopsTribe fase 1

Ho passato settimane a pensare quale nuovo nome dare al blog e alla fine ho scelto DevopsTribe.

Non è stata una scelta facile vista l’enorme quantità di spunti che mi proponevo da solo. Il nome è importante perchè ti serve nel momento in cui condividi a qualcuno il tuo blog.

Tipo…

Hey ti passo il mio blog, titolohackeroso.com (è rischioso avere la parola hacker nell’indirizzo… Fa troppo bimbo cibernetico indaco).

Hey ti passo il mio blog, comegestiresistemi.com (tipo wiki-how o qualcosa di aranzulliano… non ci piace).

Hey ti passo il mio blog, .com (serve un dominio di secondo livello).

Hey ti passo il mio blog, devops$qualcosa.it (questo mi piace. Faccio robe devops per cui ci sta).

Rimaneva quindi da definire il $qualcosa da attaccare a devops.

devops.it? (già preso..)
devopsattack.it (pare tipo ArtAttack, meglio di no)

head.jpg

devopsbofh.it (un nome, una contraddizione. Le operation agili contro la vecchia ma saggia scuola BOFH)

devopsparty.it (meglio un rave party che un party di smanettoni)

Alla fine ho scelto “tribe”.

Tribe come le mitiche Korg Electribe ES1 mkII e Korg Electribe EA1

…e tribe come la community che non può mancare intorno alle tematiche su cui lavoro.

Tribe anche come RomeDevopsTribe che è un meetup e prossimamente mi piacerebbe organizzare e vedere in attività!

Bella