OpenShift – mirror-registry disconnected change port

Привет,

По проект, който работя бе необходимо да изградим OpenShift в disconnect env. За целта използвах mirror-registry инструмента от RedHat, който създава Quay с redis и pgsql. Целта е да служи само за наливане на images, които да се използват за самата инсталация на OpenShif. Всичко е шест, но по подразбиране идва с порт 8443. Така го бях и инсталирал, но разговаряйки с разработчиците се установи, че по-добре е да си ходи на 443.

Та стъпка едно бе да подменя начинът на стартиране, говоря за услугата във файл: /etc/systemd/system/quay-pod.service конкретно publish параметър да стане: 443:8443

Вторият файл за редактиране е самият конфигурационен на Quay, намира се в /etc/quay-install/quay-config/ и параметърът е SERVER_HOSTNAME.

След което в самият OpenShift двата image-policy-{0,1} ресурса трябва да бъдат редактирани с правилните данни. Там е обтлязано къде се намира хранилището, което сме създали.

OpenShift – OADP (backup/restore application)

OADP е оператор за backup/restore на приложение в OpenShift. В основата си е пак Velero, но е интегриран в OpenShift.

За целта ще го използвам пак с Minio което имам в лабораторната среда. За демострация ще използвам проект nn-proba01. Както в предишната статия за Velero ще използвам файл с име credentials-velero със съдържание на потребител и парола за достъп до Minio.

Първа стъпка е да се инсталира оператора OADP. От списъкът си избирам този, който е сертифициран от Red Hat. Оставям всичко по-подразбиране. Той ще създаде нов namespace с гръмкото име openshift-adp

Стъпка две, създавам нов secret с име cloud-credentials във въпросният namespace, а съдържанието е гореспоменатият файл за достъп до Minio.

oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

Стъпка три, създаване на custom resource, който да е за DataProtectionApplications. В него се споменава URL до Minio, региона, bucket-a, и какви плъги да може да използва. Подробности в тяхната документация тук.

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-sample
  namespace: openshift-adp
spec:
  backupLocations:
    - velero:
        config:
          insecureSkipTLSVerify: 'true'
          profile: default
          region: minio-teo
          s3ForcePathStyle: 'true'
          s3Url: 'http://minio.lab.local:9000'
        credential:
          key: cloud
          name: cloud-credentials
        default: true
        objectStorage:
          bucket: nn-proba01
          prefix: velero
        provider: aws
  configuration:
    restic:
      enable: true
    velero:
      defaultPlugins:
        - openshift
        - aws
        - kubevirt
        - csi
  snapshotLocations:
    - velero:
        config:
          profile: default
          region: minio-teo
        provider: aws

oc create -f dataprotection.yaml

След няколко минутки ще се вдигне контейнер с velero, както и контейнер с restic. На кратко restic е инструмент за backup на PV, който е предоставен от storage, който не поддържа volume snapshots(например NFS или emptydir).

Туй то от към конфигурация, сега малко тестове. Както казах ще създам един проект nn-proba01, в него ще създам един контейнер с postgresql, който има PV 10Gi.

За да се сзъдаде backup или през web console или през oc се създава един CR за backup с такова кратко съдържание:

kind: Backup
apiVersion: velero.io/v1
metadata:
  name: backup
  namespace: openshift-adp
spec:
  defaultVolumesToRestic: true
  includedNamespaces:
    - nn-proba01

Изтривам проекта, изчаквам да ми каже че е изтрит и няма никакъв ресурс и през oc му правя възсвановяване. Разбира за теста беше хубаво да се създаде например една таблица в контейнера за да се покаже, че данните са там. Та тук ще напиша как му вкарах малко данни

$ psql
psql (10.15)
Type "help" for help.
postgres=# CREATE DATABASE dbproba01;
CREATE DATABASE
postgres=# \connect dbproba01;
You are now connected to database "restore_me" as user "postgres".
postgres=# CREATE TABLE data (
id INT PRIMARY KEY,
text VARCHAR
);
postgres=# \dt
List of relations
Schema | Name | Type | Owner
--------+------------+-------+----------
public | data | table | postgres
(1 row)
postgres=# INSERT INTO data VALUES (1,'hello there');
INSERT 0 1
postgres=# SELECT * from data;
id | text
----+-------------
1 | hello there
(1 row)

За възстановяване използвам през velero следните параметъра.

velero restore create --from-backup=backup -n openshift-adp \
--include-namespaces nn-proba01 --exclude-resources replicationcontroller,deploymentconfig,templateinstances.template.openshift.io --restore-volumes=true

Като преди това съм се вписал, разбира се. Добавил съм параметрите за exclude на ресурси, защото контейнера е от шаблона на openshift. Другият вариант е с custome resource за restore, който има следният вид.

apiVersion: velero.io/v1
kind: Restore
metadata:
  name: restore
  namespace: openshift-adp
spec:
  backupName: backup
  excludedResources:
    - nodes
    - events
    - events.events.k8s.io
    - backups.velero.io
    - restores.velero.io
    - resticrepositories.velero.io
    - replicationcontroller
    - deploymentconfig
    - templateinstances.template.openshift.io
  includedNamespaces:
    - nn-proba01
  restorePVs: true

Бърза проверка в новопоявилият се контйнер дали базата е там и данните са там. Всичко е наред.

OpenShift – velero backup/restore

Velero е софтуер за backup/restore на приложения в kubernetes. В лабораторната среда с която си играя се оказа, че има инсталиран Minio(разбира се има и nooba, но не ми се иска да цапам въпросният клъстер). Та целта на това занятие е да направя кратко backup/restore на проект в един от openshift клъстерите.

Текущо версията на velero е 1.9. Сваля се въпросният софтуер, след което се разархивира и го местя в /usr/local/bin/.

Втора стъпка, вписвам се с oc в някой от openshift клъстерите.

Трето, в произволна директория създавам файл с гръмкото име credentials-velero, съдържащ в себе си данни за вход във minio конзолата. Изглежда ето така:

[default]
aws_access_key_id = "minioadmin"
aws_secret_access_key = "minioadmin"

За да конфигурирам velero в openshift трябва да се изпълни инсталация, като това е моят пример. Посочвам име на файл с данните за вход, както и името на bucket-a, също и адресът за достъп до самото minio.

velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.2.1 \
--bucket nn-proba \
--secret-file ./credentials-velero \
--use-volume-snapshots=false \
--backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio.dev.lablocal:9000

Дават се малко права за да се вдигне velero pod:

oc adm policy add-scc-to-user privileged -z velero -n velero

Използвам namespace proba-ssd в openshift за backup/restore. Разигравам сценарии на backup, унищожение на namespace, възстановяване.

velero backup create proba-bk --include-namespaces proba-ssd

Проверка в minio, както и в самото velero за грешки:

velero backup get

Триеме нещата в openshift и правим възстановяване.

oc delete namespace proba-ssd

Проверка!

velero restore create --from-backup proba01

Проверка! И в този проект се вижда, че имах един mysql с pv.

Полезни параметри за velero:

velero restore get
velero restore describe IME
velero backup delete BACKUP_NAME

OpenShift – ceph warning 15 minutes

Кратка пред история: в лабораторната среда ми предоставиха 3 физически машини за инсталация на OpenShift върху желязо. Желязото ще бъде използвано за ODF + Virtualization.

По време на конфигурацията за мрежовата връзка за Virtulization по погрешка посочих друг мрежови интерфей и нещата замряха. Наложи се физически рестарт на машините за да ги върна отново. След време обаче забелязах, че ODF се е спънал. Та в тази кратка публикация ще споделя опит какво забелязах и как го разреших проблемът.

Забелязах, че ODF е в предупредителен режим, защопто

  1. Намерих контейнера с ceph(rook-ceph-operator)
  2. Посочих списък с променливи от конфигурацията му:
     export CEPH_ARGS='-c /var/lib/rook/openshift-storage/openshift-storage.config'
  3. Прегледах всички събития:
    sh-4.4$ ceph crash ls-new
    ID ENTITY NEW
    2022-07-20T12:44:40.615358Z_3d3593b8-0009-4f88-a340-61c798600250 osd.25 *
  4. Извадих малко повече информация за събитието:
    ceph crash info 2022-07-20T12:44:40.615358Z_3d3593b8-0009-4f88-a340-61c798600250
  5. Попадха на редове гласящи, че е имало отпадане, което беше ясно още в началото. За целта го архивирах въпросното събитие:
    ceph crash archive
  6. Повторен преглед и обеждаване, че в конзолата всичко е наред.

OpenShift – добавяне на worker node

Наложи ми се да добавя нов worker node към съществуваща инсталация на OpenShift с UPI върху VMware. Проблемът, е че съм подменил CA на OCP клъстера. Поради което използването на първичните worker.ing файлове е неуспешно. Чупи се комуникацията до api.domain.name.

Първа стъпка, вземане на текущият сертификат:

oc describe cm root-ca -n kube-system

Трябва ни съдържанието от BEGIN CERT.. до END CERT. За мое улеснение го записвам в ca.crt файл.

Ако разгледаме текущият ignition файл, ще се установи, че съдържанието на въпросният сертификат е в base64.

Втора стъпка, създаване на base64 от записаният файл

cat ca.crt | base64 -w0 > ca.crt.base64

Трета стъпка подмяна на съдържанието. За целта съм си копирал worker.ign файлът на друго място. Отварям го с любимият текстови редактор и извършвам корекция, като съдържанието изглежда нещо такова:

{"ignition":{"config":{"merge":[{"source":"https://api.domain.name:22623/config/worker"}]},"security":{"tls":{"certificateAuthorities":[{"source":"data:text/plain;charset=utf-8;base64, <съдържанието на ca.crt.base64>" }]}},"version":"3.2.0"}}

След запис, тъй като използвам VMware трябва файлът да го направя отново на base64 и съдържанието да го подам на него. С това нещата приключват. Ако инсталацията ни е например за baremetal то готовият ignition файл, трябва да бъде прехвърлен върху достъпен webserver и посочен по време на инсталацията на CoreOS.

OpenShift – премахване на проект

В този контейнизиран свят, доста често се налага да създавам/трия проекти. Второто по-често. Оказва се, че поради някаква причина не винаги това е успешно. При умишленото му указване то да е с параметър “force”.

Проект в OpenShift: nginx-ingress

Като например това:

kubectl delete ns nginx-ingress --force --grace-period=0

Решението понякога е това:

kubectl get namespace nginx-ingress -o json > nginx.json
vim nginx.json ( премахване на kubernetes от спецификация finalize)
kubectl replace --raw "/api/v1/namespaces/nginx-ingress/finalize" -f ./nginx.json

или с един ред:

kubectl get ns nginx-ingress -o json | jq '.spec.finalizers = []' | kubectl replace --raw "/api/v1/namespaces/nginx-ingress/finalize" -f -

Red Hat изпит

На 24 август 2021г. положих успешно Red Hat изпит Red Hat Enterprise Linux 8 (ex294).

Изпитът беше за 4 часа, като изцяло се използва технологията Ansible. Разполах с 5 машини, като 4 от тях трябва да играят различни роли(уеб сървър. дб, NFS).

Профилът ми в Red Hat.

Мигриране на MySQL

Привет,

Работя по един проект, в който се наложи да отделим mysql на друг физически диск. Пред историята, виртуална машина със zabbix, която се обслужва от vmware хост. В даден момент се освободи хардуерен ресурс и реших да увелича малко ресурът и на виртуалната машина. Което пък ме накара да се замисля, дали не е добре да отделя и базата за zabbix. Машината е с debian 10, zabbix с apache и mysql, като всичко вирееше на един диск 50 gb.

В кратце планът е следния:

  • гася машината
  • добавям диск
  • спирам услугата mysql
  • създавам lvm върху новият диск
  • монтирам в /mnt
  • копирам /var/lib/mysql в /mnt
  • размонтиране, монтиране във /var/lib/mysql
  • старт на mysql и тест

Добавянето на вторият диск към виртуалната машина от vmware е елементарно, като първо обнових машината след което е загасих.

root@zabbix:~# apt-get update && apt-get upgrade -y && poweroff

Загасих zabbix server услугата, както и агента и mysql-a.

root@zabbix:~# systemctl stop zabbix-server mysql zabbix-agent

Новият диск, очаквано беше sdb(проверка може да бъде направена с fdisk -l). Както ме учил майстора на bash-a, колегата Стоян Маринов – винаги LVM!

fdisk /dev/sdb (p, n, enter, enter, enter, t - 8e)

Върху създаденият дял:

pvcreate /dev/sdb1
vgcreate mysql-vg01 /dev/sdb1
lvcreate -l 100%FREE -n lv-data mysql-vol01

За файлова система съм си харесал ext4.

mkfs.ext4 /dev/mapper/mysql--vg1-lv--mysql

Монтиране в /mnt/

mount /dev/mapper/mysql--vg1-lv--mysql /mnt/

За копиране използвам rsync, cp също е вариант. С параметър -arv.

rsync -arv /var/lib/mysql /mnt

След приключване на копирането, повтарям rsync за всеки случай, след което демонтирам /mnt.

umount  /mnt

Преди да монтирам дялът с новата информация на правилното място, то прейменувам /var/lib/mysql на /var/lib/mysql.bak и създавам директорията mysql.

mv /var/lib/mysql /var/lib/mysql.bak
mkdir /var/lib/mysql
mount /dev/mapper/mysql--vg1-lv--mysql /var/lib/mysql
chown -R -c mysql:mysql /var/lib/mysql

Една бърза проверка с df никога не е излишна.

root@zabbix:~#  df -hT
Filesystem                        Type      Size  Used Avail Use% Mounted on
udev                              devtmpfs  5.9G     0  5.9G   0% /dev
tmpfs                             tmpfs     1.2G  8.9M  1.2G   1% /run
/dev/mapper/zabbix--vg-root       ext4       67G   37G   27G  58% /
tmpfs                             tmpfs     5.9G     0  5.9G   0% /dev/shm
tmpfs                             tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs                             tmpfs     5.9G     0  5.9G   0% /sys/fs/cgroup
/dev/mapper/mysql--vg1-lv--mysql  ext4      492G   35G  432G   8% /var/lib/mysql
/dev/sda1                         ext2      472M   49M  399M  11% /boot
tmpfs                             tmpfs     1.2G     0  1.2G   0% /run/user/0

Стартирам mysql услугата.

systemctl start mariadb

Правя опит да достъпя mysql, посредством mysql -u root -p. Всичко е наред. За финал един reboot и очаквам zabbix-a да се вдигне сам, както и се случи.

Backup etcd with Ansible

Имам подготвена среда с инсталиран Openshift 4.6 във VMware среда.

Необходимо бе да измисля начин, с който да правя backup на etcd, след което да го копирам на машината от която е извикан playbook-a. Написах си ansible playbook за целта:

---
- hosts: all
  become: yes
  gather_facts: no

  tasks:

  - debug: msg="{{ lookup('pipe','date') }}"

  - name: Test connection
    ping:

  - name: Create backup files
    shell: "/usr/local/bin/cluster-backup.sh /home/core/backup"

  - name: Copy backup files
    synchronize:
      src: "/home/core/backup"
      dest: "/backup/"
      recursive: yes
      mode: pull

  - name: Find all files that are older than 10 days
    find:
      paths: "/home/core/backup"
      age: 10d
      recurse: yes
    register: filesOlderThan10

  - name: Remove older files than 10 days
    file:
      paths: "/home/core/backup"
      state: absent
    with_items: "{{ filesOlderThan10.files }}"

  - name: Send notification Slack
    slack:
      token: "XXX/YYY/ZZZ"
      msg: 'Backup ETCD on  {{ inventory_hostname }} completed :)'
      channel: '#monitoring'
    delegate_to: localhost

След, което го вкарах в crontab и готово.

Обновяване на IOS

Привет,

Попаднаха ми 2 броя cisco catalyst 2960, 24 портови. Трябваше да се направи обновление на IOS-а, защото единият беше с 15.2-е8, а другият 12.2. Този, с по-старата версия на IOS-a, нямаше вграден и web interface. А такъв е необходим поради изискването на клиента.

Сдобих с последната препоръчителна версия за устройствата, която е 15.2-e9. Копирах tar файла съдържащ и html файловете нужни за web интерфейсът.

След което предприех стъпки да освободя малко пространство от flash:, разархивиране и прилагане:

Switch# delete flash:c2960s-universalk9-mz.122-55.SE7

Switch# archive tar /xtract usbflash0:c2960s-universalk9-tar.152-2.E9.tar flash:
Copy in progress...CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
16800768 bytes copied in 159.451 secs (105366 bytes/sec)
Switch#
Switch# conf t
Enter configuration commands, one per line.  End with CNTL/Z.

Switch(config)# boot system flash:c2960s-universalk9-mz.152-2.E9.bin

Switch# wr
Building configuration...
[OK]

Switch# reload
*Jan  2 00:10:47.196: %SYS-5-CONFIG_I: Configured from console by console

Switch#