Un laboratorio per Rancher, K8s, GlusterFS e la soluzione “del ferro economico” al quesito “dove provo tutta sta roba” #1

Ieri, per delle robe un po’ urgenti, mi occorreva avere uno stack ben definito intorno a Kubernetes.

Siccome siamo DevOps Engineer fighi ho scritto un po’ di moduli Terraform e in due minuti ho fatto tutto…

Non è vero c’ho messo tipo mezza giornata e l’ho fatto anche un po’ “a manella”.

Mi piace molto Kubernetes ma, da ormai svariato tempo, preferisco usarlo tramite Openshift soprattutto nell’ambito enterprise. Tuttavia, Rancher mi è piaciuto e lo vedo come una valida soluzione da proporre in determinati casi (magari produrrò un post del tipo Openshift Vs Rancher).

Non è comunque un’alternativa ad Openshift perchè sono due prodotti diversi.

Giuro che non ho abbandonato l’utilizzo sfrenato di Vagrant in locale sulla mia workstation ma, questa volta, ho adottato la soluzione “del ferro economico” al quesito “dove provo tutta sta roba”.

Si, alla fine ho preso in affitto una macchina su Kimsufi con Proxmox 5 che uso come laboratorio da molto tempo.

Screen Shot 2018-09-08 at 10.44.38.png

Ci provo svariate cose come diverse versioni di Openshift e la piattaforma che racconterò in questo post.

La configurazione del nodo fisico è molto semplice:

  1. Proxmox 5 (già installato da Kimsufi).
  2. Una rete locale 10.10.10.0/24 su cui attesto le virtual machine e le faccio uscire su internet.
  3. Un HaProxy installato direttamente sul nodo fisico in modo da inoltrare il traffico sulla 10.10.10.0/24 e farmi accedere da fuori.
  4. Spengo e accendo le diverse “sub-platforms” (me lo sono inventato al volo questo termine…) a seconda delle risorse che mi servono e le raggiungo tranquillamente tramite il reverse proxy.
  5. No, non è come in cloud che spengo e accendo come mi pare con la confortevole sensazione del risparmio pay as you go. Spendo sempre gli stessi soldi.
  6.  Per entrare direttamente sulle vm dal mio computer naturalmente ho impostato gli Host nella configurazione ssh.
Host gluster01
HostName 10.10.10.16
User root
ProxyCommand ssh -W %h:%p -lroot kimsufi

Host gluster02
HostName 10.10.10.17
User root
ProxyCommand ssh -W %h:%p -lroot kimsufi

Host gluster03
HostName 10.10.10.18
User root
ProxyCommand ssh -W %h:%p -lroot kimsufi

Tutto questo anche visto che il mio mac MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) quando faccio cose DevOps si scalda e accende la ventola che è abbastanza fastidiosa. Inoltre ti esponi al rischio “collega simpatico” che ti fa battute tipo << che fa decolla? >>.

Mi serviva avere questo stack in poco tempo per testare cose:

  1. Un cluster Kubernetes.
  2. Un’istanza Rancher per gestirlo.
  3. Un cluster GlusterFS in replica 3.

Screen Shot 2018-09-08 at 10.55.41

Per creare le VMs?

Volevo provare un plugin di Vagrant per Proxmox, ma non avevo tempo cui ho svolto “a manella” l’installazione di un nodo CentOS Linux release 7.5.1804 (Core) con cloning per le altre 2 virtual machine.

  • gluster01 (10.10.10.16)
  • gluster02 (10.10.10.17)
  • gluster03 (10.10.10.18)

Per installare velocemente Kubernetes?

Assolutamente KubeSpray!

È andata più o meno così

    1. Come installare Python3 su Centos 7.5 visto qui
    2. yum install git ansible
      git clone https://github.com/kubernetes-incubator/kubespray.git
      mkdir inventory/mycluster
      cp -rfp inventory/sample/* inventory/mycluster
      declare -a IPS=(10.10.10.16 10.10.10.17 10.10.10.18)
      CONFIG_FILE=inventory/mycluster/hosts.ini python3.6 contrib/inventory_builder/inventory.py ${IPS[@]}
      
    3. Prova di connessione ai nodi con ‘ansible all -i inventory/mycluster/hosts.ini -m shell -a “whoami”‘
    4. Inizio installazione
      ansible-playbook -i inventory/mycluster/hosts.ini cluster.yml

Devo dire che è andato tutto bene senza troppi intoppi.

Kubernetes cluster up and running!

[root@gluster01 kubespray]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
node1 Ready master,node 4m v1.11.2
node2 Ready master,node 4m v1.11.2
node3 Ready node 3m v1.11.2

 

Installazione di Rancher

Rancher si installa facilmente e basta dargli in pasto un cluster Kubernetes per vederlo all’opera. Nel mio caso gira come container Docker con persistenza.

 docker run -d --restart=unless-stopped -p 80:80 -p 443:443 -v /host/rancher:/var/lib/rancher rancher/rancher:latest

This slideshow requires JavaScript.

#creazione di un service account con diritti per amministrare il cluster k8s
[root@gluster01 ~]# kubectl create -f admin-user.yaml
serviceaccount/admin-user created
[root@gluster01 ~]# kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user admin-user
clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-binding created

Dopo un po’ di “smanettamenti” lato reverse proxy e DNS finalmente il cluster è in stato waiting…

Screen Shot 2018-09-08 at 15.51.53

Dopo altri “smanettamenti ” il cluster si è “joinato” correttamente a Rancher. Anzi più che “joinato” forse è meglio dire che Rancher ha eseguito un takeover su k8s.

Però ho dovuto importare un certificato nel container di Rancher con:

 docker cp /etc/pki/ca-trust/source/anchors/kube-ca.crt $idcontainerdirencher:/etc/ssl/certs/

È una cosa temporanea eh… dopo metto apposto…

Questi sono i pod attivi sul cluster nel namespace creato per Rancher

[root@node1 ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
cattle-system cattle-cluster-agent-6b8df4755-8tfxg 1/1 Running 0 2m
cattle-system cattle-node-agent-48bcq 1/1 Running 0 2m
cattle-system cattle-node-agent-928wl 1/1 Running 0 1m
cattle-system cattle-node-agent-t6cs6 1/1 Running 0 2m

Screen Shot 2018-09-08 at 16.48.38Screen Shot 2018-09-08 at 16.48.44

Installazione di GlusterFS

Sui tre nodi Gluster01,02,03 dove avevo installato Kubernetes controllato da Rancher dovevo aggiungere anche GlusterFS.

Per l’installazione niente di più semplice di questa guida

[root@node1 ~]# gluster volume info

Volume Name: gv0
Type: Replicate
Volume ID: 2a111687-5d26-4051-b0a8-8d4a67efc87f
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: gluster02:/bricks/brick1/gv0
Brick2: gluster03:/bricks/brick1/gv0
Options Reconfigured:
performance.client-io-threads: off
nfs.disable: on
transport.address-family: inet

#Lista nodi dei peer dal node1
[root@node1 ~]# gluster peer status
Number of Peers: 2

Hostname: gluster02
Uuid: 2cb83c74-ebc3-4dca-a62f-799433d198ae
State: Peer in Cluster (Connected)

Hostname: gluster03
Uuid: 6918282f-23f8-4627-b9b4-e7b9d521b32d
State: Peer in Cluster (Connected)

 

Una volta completato tutto ho potuto eseguire delle simulazioni utili per alcuni problemi su un’altra piattaforma.

Al momento sto girando dei pod con GlusterFS come persistent volume e nei prossimi articoli scenderò più nel dettaglio sull’utilizzo di Rancher.

Bella

Cos’è che fa di un Devops un Devops, signor Lebowski?

Vorrei parlare dei principi base del Devops che negli ultimi 5 anni ho potuto assimilare lungo il cammino.
Questo perchè dovevo preparare delle noiosissime slide. Mi serviva uno scopo, e un post sul blog ci sta tutto.

Inoltre, ho preso il dominio ziopinguino.it e sto pensando di migrare tutto il blog lì…

Quali sono i caratteri distintivi dell’area Devops?
Quali sono gli stereotipi e le considerazioni ricorrenti tipiche degli ambiti innovativi a cavallo tra buzzword e vera innovazione?

Cos’è che fa di un devops un devops, signor Lebowski?

Essere una BaaS? Buzzword as a service?

Lo era sicuramente all’inizio una buzzword, ma ora non più.
Lo è se si legge solo nei blog di Devops, se non si è potuto toccarne con mano i benefici e i risultati.

Nei contesti dove c’è stata una vera rivoluzione, la parola “Devops” descrive perfettamente figure professionali che svolgono attività di collegamento tra i…

View original post 798 more words

Autenticazione con Ansible. Esempi di vari casi (ssh key, sudo, su, password,…)

Spesso, a seconda dell’environment in cui ci troviamo e delle restrizioni che dobbiamo affrontare lato sicurezza, dobbiamo effettuare un tuning del nostro inventory file.

Riporto in questo post un po’ di casi diversi che possono essere utili come esempi di configurazione base.

Sono casi molto semplici ma uniti insieme possono essere una visione d’insieme rapida sui parametri disponibili da usare nell’inventory.

Scambio chiavi ssh

Il default user per le connessioni ssh è root. La chiave pubblica dell’utente da cui sto lanciando Ansible è stata inserita in /root/.ssh/authorized_keys di root in ocslave35.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35
ansible nodes -m ping
ocslave35 | SUCCESS => {
"changed": false,
"ping": "pong"
}

Autenticazione con password

Definisco la password di root di ocslave35.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_ssh_pass=supersecret_password
ansible nodes -m ping
ocslave35 | SUCCESS => {
"changed": false,
"ping": "pong"
}

Utilizzo utente operatore con password

Definisco un utente operatore con relativa password.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_user=operatore ansible_ssh_pass=foobar.123
[root@ocmaster35 ~]# ansible nodes -m shell -a "whoami"
ocslave35 | SUCCESS | rc=0 >>
operatore

become_method sudo

L’utente operatore diventa root tramite sudo

[root@ocslave35 ~]# cat /etc/sudoers.d/operatore
operatore ALL=(ALL) ALL
#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_user=operatore ansible_ssh_pass=foobar.123 ansible_become_user=root ansible_become=yes ansible_become_method=sudo ansible_become_pass=foobar.123
[root@ocmaster35 ~]# ansible nodes -m shell -a "whoami"
ocslave35 | SUCCESS | rc=0 >>
root

become_method su

L’utente operatore diventa root tramite il comando su con password definita nell’inventory.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_user=operatore ansible_ssh_pass=foobar.123 ansible_become_user=root ansible_become=yes ansible_become_method=su ansible_become_pass=supersecret_password
[root@ocmaster35 ~]# ansible nodes -m shell -a "whoami"
ocslave35 | SUCCESS | rc=0 >>
root

 

Accesso locale

Il nodo da cui lanciamo Ansible è lo stesso a cui vogliamo connetterci. Non c’è bisogno di ssh quindi.

[nodes]
ocmaster35 ansible_connection=local

ciao!

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 !