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 да се вдигне сам, както и се случи.

Netbox installation Centos 8

Netbox е супер инструмент, служещ да ни помогне в управлението и документирането на компютърни мрежи. Първоначално замислена от екипа за мрежово инженерство в DigitalOcean, NetBox е разработена специално, за да отговори на нуждите на мрежовите и инфраструктурни инженери. В процеса на работа не винаги съм се натъквал на добре документирано хардуерно/софтуерно съдържание при клиент, което почти винаги е забавяло процесът на работа. Попадах няколко пъти на въпросният инструмент, но не намирах време да го разгледам. Е оказа се за мойте нужди, направо превъзходен. Първите тестове бяха в контейнер на локалната ми машина, но го исках на виртуална машина. Самият софтуер е написан на python + django, за база от данни се използва postgresql, с много приятен(изчистен) и динамичен уеб интерфейс. Може да се направи интеграция с активна директория.

В публикацията ще опиша, по какъв начин съм го инсталирал във виртуална среда.

Машината е с минимален хардуерен ресурс 2vCPU, 4 GiB ram, 50 HDD. Върху нея ще инсталирам CentOS8 от netinstall. Нищо не обичайно или сложно. Само съм му забранил FirewallD и SELinux.

Следваща стъпка, документацията на Netbox.

Първо се инсталира PostgreSQL. Текущо в хранилището на Centos8 е версия 10.14. След инсталация се инициализира, извършва се корекция в конфигурацията на pgsql за да работи с md5, услугата се стартира, разрешава за автоматично стартиране със зареждане на операционната система и създаване на база от данни, потребител/парола за нуждите на инструмента.

dnf install postgresql postgresql-server
postgresql-setup --initdb

Редакция на конфигурационният файл на postgresql: ident става md5

vim /var/lib/pgsql/data/pg_hba.conf
host all all 127.0.0.1/32 md5 
host all all ::1/128 md5

Стартиране и добавяне в auto-start:

systemctl enable postgresql
systemctl start postgresql

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

sudo -i -u postgres psql

postgres=# CREATE DATABASE netbox;
CREATE DATABASE
postgres=# CREATE USER netbox WITH PASSWORD 'strongpassword';
CREATE ROLE
postgres=# GRANT ALL PRIVILEGES ON DATABASE netbox TO netbox;
GRANT
postgres=# \q

Инсталиране на Redis, добавяне в auto-start и стартиране на самият процес.

systemctl enable redis
systemctl start redis
systemctl status -l redis

#test
redis-cli ping

Инсталиране на системни пакети

dnf install -y gcc python38 python38-devel python38-setuptools libxml2-devel libxslt-devel libffi-devel openssl-devel redhat-rpm-config git
pip3 install --upgrade pip

Изтегляне на NetBox. В документацията им използват, като работна директория /opt/netbox, в примера ще го използвам и аз.

mkdir -p /opt/netbox/ && cd /opt/netbox/
git clone -b master https://github.com/netbox-community/netbox.git .

Добавяне на системен профил за netbox. Ще конфигурираме услугите WSGI и HTTP да работят под този акаунт. Също така ще присвоим това потребителско право на собственост върху медийната директория. Това гарантира, че NetBox ще може да запазва качени файлове.

groupadd --system netbox 
adduser --system -g netbox netbox
chown --recursive netbox /opt/netbox/netbox/media/

Конфигуриране на Netbox. В директорията /opt/netbox/netbox/netbox/ има примерен конфигурационен файл(configuration.example.py), който ще го копираме в същатата директория но с друго име: configuration.py. С любимото Vim го отварям и извършвам лека корекция, настройка на ALLOWED_HOSTS(списък с валидните имена на хостове и IP адреси, чрез които може да се достигне до този сървър), данни за базата от данни, данни за redis сървъра.

cd /opt/netbox/netbox/netbox/
cp configuration.example.py configuration.py
vim configuration.py

ALLOWED_HOSTS = ['netbox.devops.lab, '172.16.16.10']
DATABASE = {
'NAME': 'netbox', # Името на DB-то, което създадохме
'USER': 'netbox', # потребителско име за db
'PASSWORD': 'strongpassword', # парола
'HOST': 'localhost', # db server
'PORT': '', # Database port (leave blank for default)
'CONN_MAX_AGE': 300, # Max database connection age (seconds)
}

REDIS = {
'tasks': {
'HOST': 'localhost', # Redis server
'PORT': 6379, # Redis port
'PASSWORD': '', # Redis password (optional)
'DATABASE': 0, # Database ID
'SSL': False, # Use SSL (optional)
},
'caching': {
'HOST': 'localhost',
'PORT': 6379,
'PASSWORD': '',
'DATABASE': 1, # Unique ID for second database
'SSL': False,
}
}

SECRET_KEY=?

Трябва да се генерира secret key, като от netbox са написали инструмент за генерирането му.

python3 ../generate_secret_key.py

Създаване на административен потребил за достъп до Netbox.

source /opt/netbox/venv/bin/activate
(venv) # cd /opt/netbox/netbox
(venv) # python3 manage.py createsuperuser
Username: admin
Email address: admin@example.com
Password:
Password (again):
Superuser created successfully.

Тест на приложението:

python3 manage.py runserver 0.0.0.0:8000 --insecure

След това се свържете с името или IP на сървъра (както е дефинирано в ALLOWED_HOSTS) на порт 8000; например http://172.16.16.10:8000/ . Трябва да бъдете посрещнати с началната страница на NetBox.

Настройка на systemd

Ще използваме systemd, за да контролираме както gunicorn, така и фоновия работен процес на NetBox. Първо копирайте contrib/netbox.service и contrib/netbox-rq.service в /etc/systemd/system/ директорията и презаредете systemd dameon:

cp contrib/*.service /etc/systemd/system/
systemctl daemon-reload

systemctl start netbox netbox-rq
systemctl enable netbox netbox-rq

До тук добре, но е хубаво вместо да го отварям на порт 8000 да го зареждам директно с името на домейна. За целта ще инсталираме един apache уеб сървър.

yum install httpd -y
systemctl enable httpd
systemctl start httpd

cp /opt/netbox/contrib/apache.conf /etc/httpd/sites-available/netbox.conf
cp /opt/netbox/contrib/apache.conf /etc/httpd/sites-enabled/netbox.conf

yum install mod_proxy_html -y
service httpd restart

После в любим уеб браузър се отваря въпросното IP или ако има DNS запис.

Успех!

Официално съм Red Hat Certified Engineer

В началото на годината започнах едно ново професионално пътешествие. След кратък разговор с началника, той ме убеди, че трябва да придобия квалификацията Red Hat Certified Engineer. Целта е ясна. За да се придобие въпросната квалификация, трябваше да взема два изпита Red Hat Certified System Administrator(EX200) и Red Hat Certified Engineer(EX300).

Ключа към успеха се криеше в многото практика, отново и отново. Бях си изградил един setup с vagrant и в деня не помня по колко up/destroy -f съм писал. За двата сертификата отделих може би над 80 часа.

Аз @ Red Hat

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 сървър и достъп до нея).

Това е. 🙂