Daily Business mit OpenShift

Bei der Post läuft täglich um 24:00 ein cronjob, der alle wichtigen Projekt-Ressourcen täglich exportiert:

#!/bin/bash
BACKUP_DIR="/var/openshift_backup/"
BACKUP_DIR_WITH_DATE=${BACKUP_DIR}/backup_$(date +%Y%m%d%H%M)

### Remove folders older than 30days
find ${BACKUP_DIR} -maxdepth 1 -ctime +30 -type d -exec rm -rf {} \;

### Setup
mkdir -p $BACKUP_DIR_WITH_DATE

### Project Backup
# Check if executed as OSE system:admin
if [[ "$(oc whoami)" != "system:admin" ]]; then
  echo -n "Trying to log in as system:admin... "
  oc login -u system:admin > /dev/null && echo "done."
fi

# Backup all resources of every project
for project in $(oc get projects --no-headers | awk '{print $1}')
do
    echo -n "Backing up project $project... "
    mkdir -p ${BACKUP_DIR_WITH_DATE}/projects/${project}
    oc export all -o yaml -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/project.yaml 2>/dev/null
    oc get rolebindings -o yaml -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/rolebindings.yaml 2>/dev/null
    oc get serviceaccount -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/serviceaccount.yaml 2>/dev/null
    oc get configmap -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/configmap.yaml 2>/dev/null
    oc get daemonset -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/daemonset.yaml 2>/dev/null
    oc get secret -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/secret.yaml 2>/dev/null
    oc get pvc -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/pvc.yaml 2>/dev/null
    oc get statefulset -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/statefulset.yaml 2>/dev/null
    oc get buildconfigs -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/buildconfigs.yaml 2>/dev/null
    oc get builds -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/builds.yaml 2>/dev/null
    oc get imagestreams -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/imagestreams.yaml 2>/dev/null
    oc get jobs -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/jobs.yaml 2>/dev/null
    oc get route -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/route.yaml 2>/dev/null
    oc get services -o yaml --export=true -n ${project} > ${BACKUP_DIR_WITH_DATE}/projects/${project}/services.yaml 2>/dev/null
    echo "done."
done

Dieser legt die Files in folgender Struktur auf dem ersten Master ab:

/var/openshift_backup/
├── backup_201806190000
│   └── projects
│       ├── appuio-infra
│       ├── default
│       ├── glusterfs
│       ├── kube-public
│       ├── kube-service-catalog
│       ├── kube-system
│       ├── logging
│       ├── management-infra
│       ├── ocp-grafana
│       ├── openshift
│       ├── openshift-ansible-service-broker
│       ├── openshift-infra
│       ├── openshift-metrics
│       ├── openshift-node
│       ├── openshift-template-service-broker
│       ├── openshift-web-console
│       └── patricks-testprojekt
├── backup_201806200000
│   └── projects
│       ├── appuio-infra
│       ├── default
│       ├── glusterfs
│       ├── kube-public
│       ├── kube-service-catalog
│       ├── kube-system
│       ├── logging
.....

Restore erfolg durch ein simples erstellen der Ressourcen. Zum Beispiel:

# oc create -f "Backup file in yaml" -n "namespace"

Das Überwachungsskript(/root/openshift-script/check_gluster_volumes.sh) hat folgende E-Mail in die Mailbox SMSOPENSHIFTDL@post.ch gesendet. Dieselbe Fehlermeldung wird auch im HP-OVO Monitoring angezeigt.

Development Platform > DailyBusiness > 1.png

Auf dem Glusternode vekq7k wurde wegen eines anderen Fehler ein Neustart des Servers gemacht. Anschliessend konnte GlusterFS nicht vollständig gestartet werden. Somit muss das GlusterFS auf auf dem gluster-pv101 forciert neu gestartet werden:

[root@vekq7k ~]# gluster volume status gluster-pv101 Status of volume: gluster-pv101 Gluster process TCP Port RDMA Port Online Pid

Brick vhmsgj.pnet.ch:/data/gluster-pv101/br ick 49152 0 Y 6846 Brick vkyg7l.pnet.ch:/data/gluster-pv101/br ick 49152 0 Y 4553 Brick vsytjw.pnet.ch:/data/gluster-pv101/br ick 49152 0 Y 4939 Brick vu32g5.pnet.ch:/data/gluster-pv101/br ick 49152 0 Y 6774 Brick vpva0p.pnet.ch:/data/gluster-pv101/br ick 49152 0 Y 8864 Brick vekq7k.pnet.ch:/data/gluster-pv101/br ick 49202 0 Y 82665 Brick vlf5eh.pnet.ch:/data/gluster-pv101/br ick 49152 0 Y 103339 Brick vw7w5k.pnet.ch:/data/gluster-pv101/br ick 49152 0 Y 6902 Brick v2o8fv.pnet.ch:/data/gluster-pv101/br ick 49152 0 Y 3353 Self-heal Daemon on localhost N/A N/A Y 82687 Self-heal Daemon on v2o8fv.pnet.ch N/A N/A Y 42526 Self-heal Daemon on vs3tvs.pnet.ch N/A N/A Y 99276 Self-heal Daemon on vw7w5k.pnet.ch N/A N/A Y 18084 Self-heal Daemon on vsytjw.pnet.ch N/A N/A Y 4673 Self-heal Daemon on vhmsgj.pnet.ch N/A N/A Y 31894 Self-heal Daemon on vlf5eh.pnet.ch N/A N/A Y 22477 Self-heal Daemon on vkyg7l.pnet.ch N/A N/A Y 57012 Self-heal Daemon on vpva0p.pnet.ch N/A N/A Y 37754 Self-heal Daemon on vu32g5.pnet.ch N/A N/A Y 85923 Self-heal Daemon on vthbcn.pnet.ch N/A N/A Y 117650

Task Status of Volume gluster-pv101

There are no active volume tasks

[root@vekq7k ~]# gluster volume start gluster-pv101 force

Funktioniert der oc get command nicht mehr korrekt, oder besser gesagt wird hier ein Passwort verlangt, so ist die Kube Config verschossen.. Ein gültiges Backup befindet sich hier: /etc/origin/master/admin.kubeconfig

# cp /etc/origin/master/admin.kubeconfig .kube/config

Damit mittels “ansible” Kommando von einem Master Node auf andere Nodes verbunden werden kann, braucht es folgende Einrichtungen

Aktuelles Hosts Inventory File /etc/ansible/hosts (manuell) SSH Private Key unter /root/.ssh/id_rsa (manuell) Ansible SSH Prublic Key unter /etc/ssh/authorized_keys/ansible (wird mit Puppet verteilt) [root@vosm01 ~]# ls -lsa /root/.ssh/ total 16 0 drwx——. 2 root root 39 Feb 28 2017 . 4 dr-xr-x—. 36 root root 4096 Aug 20 16:23 .. 4 -r——–. 1 root root 1680 Feb 28 2017 id_rsa 8 -rw-r–r–. 1 root root 4508 Sep 14 2017 known_hosts [root@vosm01 ~]# ls -lsa /etc/ansible/hosts 0 lrwxrwxrwx. 1 root root 42 Mar 6 17:10 /etc/ansible/hosts → /root/openshift-hostfiles/hosts_osit2.yaml [root@vosm01 ~]# [root@vosm01 ~]# ls -lsa /root/.ssh/ total 16 0 drwx——. 2 root root 39 Feb 28 2017 . 4 dr-xr-x—. 36 root root 4096 Aug 20 16:23 .. 4 -r——–. 1 root root 1680 Feb 28 2017 id_rsa 8 -rw-r–r–. 1 root root 4508 Sep 14 2017 known_hosts [root@vosm01 ~]# [root@vosm01 ~]# ls -lsa /etc/ssh/authorized_keys/ansible 4 -r——–. 1 ansible ansible 389 Jan 27 2017 /etc/ssh/authorized_keys/ansible [root@vosm01 ~]#

Eine zusätzliche Terabyte Disk auf dem Gluster Cluster via Heketi einbinden: (siehe auch : https://access.redhat.com/solutions/3164841)

Login auf dem OpenShift GUI, Project “glusterfs”, Pod “heketi-storage”.

Zuerst die Admin Credientials über das YAML-File vom Pod “heketi-storage” auslesen.

Development Platform > DailyBusiness > image2019-1-25_14-29-55.png

Auf der Heketi-Pod Konsole node und Cluster ID auslesen.

sh-4.2# heketi-cli node list –user admin –secret p/J+OhZgDjwuMy/vZBoD74hP4CWmjWWE32ye6czr2aU= Id:0680dabe91ee5a7f36da8cb6fe49cdd4 Cluster:7234de4476a10cb0d138e3fd3d387c40 Id:648f2115e99bf41fb78271acd55bd8f9 Cluster:7234de4476a10cb0d138e3fd3d387c40 Id:b016e52ee7378debc04427385f81cd82 Cluster:7234de4476a10cb0d138e3fd3d387c40

Jetzt kann das neue Device nach dem Schema “hecketi-cli device add –name /dev/DISK –node NODE_ID” für jede Node-ID des Clusters auf der Pod-Konsole eingegeben werden.

sh-4.2# heketi-cli device add –name /dev/sdc –node 0680dabe91ee5a7f36da8cb6fe49cdd4 –user admin –secret p/J+OhZgDjwuMy/vZBoD74hP4CWmjWWE32ye6czr2aU= Device added successfully

sh-4.2# heketi-cli device add –name /dev/sdc –node 648f2115e99bf41fb78271acd55bd8f9 –user admin –secret p/J+OhZgDjwuMy/vZBoD74hP4CWmjWWE32ye6czr2aU= Device added successfully

sh-4.2# heketi-cli device add –name /dev/sdc –node b016e52ee7378debc04427385f81cd82 –user admin –secret p/J+OhZgDjwuMy/vZBoD74hP4CWmjWWE32ye6czr2aU= Device added successfully

Als Resultat der Erweiterung, sieht man nun auf dem entsprechenden Node mit dem Kommando “pvscan” die von heketi neu bereitgestellte Volumegroup.

[root@vosge1 ~]# pvscan

PV /dev/sdc    VG vg_5e4ce3cca0b61f43f749d3cef0447e2e   lvm2 [999.87 GiB / <979.72 GiB free]
PV /dev/sdb    VG vg_bc2782bf157d2cde474ff55ae298715f   lvm2 [999.87 GiB / 5.40 GiB free]
PV /dev/sda2   VG vgsys                                 lvm2 [<79.47 GiB / 0    free]
Total: 3 [2.03 TiB] / in use: 3 [2.03 TiB] / in no VG: 0 [0   ]

Red Hat Anleitung: https://docs.openshift.com/container-platform/3.10/install_config/adding_hosts_to_existing_cluster.html

Die neuen Hosts müssen in eine der folgenden beiden Firewall Gruppen, damit sie die nötigen Firewalls geschaltet bekommen (Je nach Plattform unterschiedliche FW-Rules): WICHTIG: Wenn die Änderungen vorgenommen wurden, muss die Gruppe implementiert werden!

Nonprod: IT-OShift-SharedNodeTest-M02A4-X Prod: IT-OShift-SharedNodeProd-M02A4-X

Mit folgendem Ansible Befehl kann überprüft werden, ob die FW Rules geschaltet wurden:

[rebermi@vosbh1]# ansible -i hosts_shared.yaml vosne5.pnet.ch,vosnz5.pnet.ch -m shell -a “date”

Bevor der neue Host dem Cluster hinzugefügt werden kann, muss dieser die nötigen OpenShift Pakete erhalten. Hierzu muss das Package “atomic-openshift-utils” installiert werden. Jedoch wird dieses nur bis zur Version 3.9 gepflegt. Deshalb müssen zuerst unter /etc/yum.repos.d/ose.repo die 3.9 OpenShift Repos angehängt werden. Erst danach kann das Paket mit yum installiert werden:

[root@new_host]# vim /etc/yum.repos.d/ose.repo [rhel-7-server-ose310-rpms] baseurl = http://vinstp.pnet.ch/distributor/testing/rhel7-server-$basearch/ose/3.10 enabled = 1 gpgcheck = 1 gpgkey = file:/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release name = Red Hat OpenShift Container Platform 3.10 (RPMs) [rhel-7-server-ose39-rpms] baseurl = http://vinstp.pnet.ch/distributor/testing/rhel7-server-$basearch/ose/3.9 enabled = 1 gpgcheck = 1 gpgkey = file:/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release name = Red Hat OpenShift Container Platform 3.9 (RPMs)

[root@new_host]# yum install atomic-openshift-utils -y [root@new_host]# systemctl reboot

Der Host ist nun bereit. Jetzt muss das Hostfile angepasst werden (siehe ←–):

[rebermi@vosbh1]# vim openshift-hostfiles/hosts_shared.yml — all:

children:
  OSEv3:
    children:
      bastion: {}
      glusterfs: {}
      glusterfs_registry: {}
      etcd: {}
      masters: {}
      nodes:
        children:
          masters: {}
          infra_nodes: {}
          user_nodes: {}
          new_nodes: {}  <---

…

  user_nodes:
    hosts:
      EXISTING_HOSTS.pnet.ch:
        openshift_hostname: vosne1.pnet.ch
        openshift_ip: 172.18.184.14
        openshift_node_group_name: node-config-compute-eh-prod
        openshift_node_local_quota_per_fsgroup: 1Gi
  new_nodes: <---
    hosts:
      NEW_HOST.pnet.ch:
        openshift_hostname: NEW_HOST.pnet.ch
        openshift_ip: IP_ADRESS
        openshift_node_group_name: node-config-compute-eh-test
        openshift_node_local_quota_per_fsgroup: 1Gi

Zum Schluss muss nun das Scaleup Playbook von Red Hat ausgeführt:

ansible-playbook [-i /path/to/file] /usr/share/ansible/openshift-ansible/playbooks/openshift-node/scaleup.yml

Damit auch Pods auf den neuen Cluster-Nodes erstellt werden können, muss man die LABELS der Nodes anpassen:

[user@vosbh1 ~]$ oc login https://plattform.pnet.ch [user@vosbh1 ~]$ oc get nodes –show-labels

# Man kann jetzt die Labels eines funktionierenden Nodes kopieren und folgendermassen diesen labeln:

[user@vosbh1 ~]$ oc label node NEWNODE compute=true [user@vosbh1 ~]$ oc label node NEWNODE region=primary [user@vosbh1 ~]$ oc label node NEWNODE stage=test [user@vosbh1 ~]$ oc label node NEWNODE zone=defaul

Die Labels sollten je nach Node angepasst werden (EH/ZF , stage=test / stage=prod , usw.)