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 – добавяне на 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 -

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 и готово.

Simple Flask Containerized

Simple Flask app containerized

Накратко, наложи ми се да пусна OpenShift с Flask приложение, което се оказа много добър учил. Реших да задълбая и да си направя свой контейнер работещ на моята машина с Flask microframework. 

Сценария е разигран върху Debian и Docker CE(текущо 18.06.1-ce). Пгорамата(app.py) е проста, отпечатва текст в уеб браузър.

Файл „app.py“ е със съдържание:

from flask import Flask
app = Flask(name)

@app.route('/')
def hello_world():
return 'Hello from Flask'
if name__ == '__main':
app.run(debug=True,host='0.0.0.0')

Ще ми трябва и файл requirements.txt, който е със съдържанието на нужните библиотеки за да сработи приложението. Тъй като стъпва на Flask, в него има само един ред – „Flask“

Всичко стъпва върху alpine(като най-малък image) и в него се инсталира python.

Dockerfile -a е със съдържание:

FROM alpine:latest
MAINTAINER Nikolay Nikolov "nikolay.nikolov@cnsys.bg"
RUN apk add --update \
python \
python-dev \
py-pip \
build-base
COPY . /app
WORKDIR /app
RUN pip install -r /app/requirements.txt
ENTRYPOINT ["python"]
CMD ["app.py"]

И 3-те файла се намират в произволно създадена директория.

Правим Build/Run за тест

docker build -t flask-app:latest .

docker run -d -p 5000:5000 flask-app

В уеб на локалния адрес и порт 5000, ще се види работещо приложението.

OpenShift Container Platform 3.10

От началото на година усилено съм се съсредоточил върху инсталиране/конфигуриране и разучаването на OpenShift. След усилена борба, успях да му надвия.

Ситуацията е следната, написах playbook, който разпъва OpenShift ent(container platform 3.10) върху 1 master, 3 nodes, 3 gluster registry.
Много съм доволен от себе си 🙂

Следваща стъпка, 3 master, 3 nodes, 3 gluster registry, 1 load balancer. 

Същевременно изкарах и сертификат от Red Hat с гръмкото име „Red Hat Delivery Specialist – Platform-as-a-Service (PaaS) Administration“.

OpenShift – wordpress

От началото на годината се уча на OpenShift origin. Разполагам с подготвена инфраструктура, състояща се от един master и един node. Но не това е важното, а по какъв начин може да се инсталира и подготви WordPress в тази среда.

След като сме вписани в уеб интерфейсът на master и имаме създаден проект(например: wordpress-mysql), от менюто се избира „Import YAML / JSON“.
В официалното хранилище на openshift в github може да бъде намерен въпросният JSON файл. Избираме как ще се казва проекта и поставяме съдържанието на JSON файла и изпълняваме бутонът „Create“.
Следващата стъпка е конфигурационна. По подразбиране е посочено хранилището за source на WordPress в github. Ако трябва се извършват нужните корекции(например потребител, паролата на базата от данни?).

След като вече имаме двата контейнера, единият съдържа mysql-a, а вторият е със самото приложение на wordpress.
Зарежда се в тази с wordpress-a в уеб браузър и се следват стъпките за инсталация на WordPress, като въвеждане на конфигурационна информация(потребител, адрес на mysql сървър и достъп до нея).

Това е. 🙂