2022-09-21
DevOps to znajomość wielu technologii na raz!
Nie. DevOps składa się jeszcze z określonego stylu pracy (często Agile), uproszczonych procesów, kontroli pracy przez stosowanie odpowiednich narzędzi (np. Jira) oraz przede wszystkim – odpowiedniego zespołu, dobranego jako mix umiejętności, gdzie nikt nie zamyka się w swoim technologicznym kąciku, każdy pomaga każdemu i każdy bierze odpowiedzialność za sukces całego projektu.
DevOps to stosowanie odpowiednich narzędzi!
Nie. To że organizujesz sobie pracę przeklejając karteczki między TODO, WORKING i DONE nie oznacza, że jesteś DevOps. To oznacza tylko, że… lubisz przeklejać karteczki. DevOps to jeszcze odpowiednie nastawienie do pracy, model pracy i szeroki zakres wiedzy technologicznej
Jedyny cel DevOpsa to szybkie dostarczanie oprogramowania
Nie. Oczywiście po to, ta metoda została wymyślona, ale to nie jedyny cel. Chodzi również o to aby oprogramowanie miało dobrą, potwierdzoną częstymi testami jakość, było skalowalne, możliwe do przeniesienia z jednego środowiska do innego , stabilne, ciągle rozwijane. Cała ta praca ma być wykonywana przez otwarty zespół dzielący się doświadczeniami, pomagający sobie wzajemnie, tak aby praca była nie tylko efektywna ale jeszcze mało stresująca i dająca satysfakcję.
DevOps to Agile
Nie. Agile to częsty element DevOpsa, ale nie jego baza. Mamy jeszcze inne metody jak np. Lean, Extreme Programming, które z powodzeniem mogą być wykrzystywane w DevOps. Agile skupia się na szybkiej produkcji oprogramowania, ale w duzej mierze pomija kwestie współpracy w zespole, na dodatek Agile może być śmiało implementowany w zespole zorganizowanym w osobne wyspecjalizowane działy, zwany często silosami.
Jest ścisła definicja tego, jak ma wyglądać DevOps
Nie. Co kraj, to obyczaj. DevOps jest budowany przez ludzi, a ludzie są różni. DevOps może wyglądać inaczej w zależności od tego kto trafił do zespołu, jakie ma umiejętności, charakter, w jakim kraju ten zespół pracuje, albo czy jest międzynarodowy! Na dodatek każda firma, ma nieco inne plany i zasady pracy, dlatego DevOps, to raczej zbiór zaleceń niż ścisłych reguł.
2022-09-20
DevOps to popularna metoda na organizację pracy związanej z produkcją oprogramowania. Pojęcie DevOps bywa różnie rozumiane i już właściwie z tym pierwszym zdaniem jest pewien problem. Niektórzy traktują DevOps bardziej jako filozofię lub „mindset” charakteryzujący ludzi współpracujących nad projektem, inni z kolei skupiają się na szerokim zakresie technologii, który musi zostać opanowany przez inżyniera DevOps, jeszcze inni kojarzą DevOps z narzędziami pracy jak np. Jira, PipeLines albo procesami build & deployment.
I rzeczywiście najlepiej jest traktować DevOps jako zbiór: zachowań i kultury współpracujących programistów i inżynierów, procesów, w ramach których oni pracują oraz technologii i narzędzi z jakich korzystają. W zależności od firmy, większa waga będzie przyłożona do tego lub innego elementu składowego, ale każdy z nich w jakimś stopniu musi występować.
Gdyby nikt nie wymyślił pojęcia DevOps, to pewnie nazwalibyśmy go ekstremalną automatyzacją w programowaniu, bo przecież celem pracy programisty i inżyniera jest szybkie tworzenie kodu, testowanie go i dostarczanie do klienta. Ma być nie tylko szybko, ale jeszcze dobrze pod względem jakości, a co poniekąd z tego wynika – może nie tanio, ale ekonomicznie, a przyjęło się sądzić, że to niemożliwe żeby było szybko, dobrze i tanio. Jak to jest osiągane?
- Programista, jak to programista – zamienia kofeinę i pizzę w kod. Tak jak zwykle to robił, wysyła swój kod do repozytorium kodu (GitHub, GitLab, etc). I tu zaczyna się akcja. Programista chciałby prędko swój kod zobaczyć w akcji i przetestować go. Dlatego…
- Po przesłaniu kodu uruchamia się proces, który automatycznie buduje rozwiązanie, np. w zależności od potrzeb kompiluje go, umieszcza gdzie trzeba…
- Wykonuje serię automatycznych testów, które potwierdzają, czy kod jest dobry czy wadliwy. Jeśli wszystko się udało, to…
- Dostarcza go do docelowego środowiska – tam testom podlega już nie pojedynczy komponent, ale cała aplikacja. Jeśli wszystko poszło dobrze – programista dostaje łyk coli
Sęk w tym, że ten automatyczny proces trzeba umieć zbudować. Dlatego może i mniej programista, ale bardziej inżynier musi zbudować ów potok zdarzeń, utrzymać go, zrozumieć aplikację i jej wymogi. A wymogi aplikacji są różne.
Mamy setki języków programowania, baz danych, metod uwierzytelnienia, mechanizmów zabezpieczających itp. Z tego wynika konieczność znajomości wielu różnych technologii. Nie wystarczy już świetnie znać system operacyjny. Trzeba umieć poskładać całą aplikację! Nie zapominajmy przy tym, że obecnie aplikacja, to coraz rzadziej jeden plik exe, który gdzieś należy wgrać. Aplikacja zwykle korzysta z kilku serwerów, baz, interfejsów łączących tą aplikację z innymi systemami itp. Dlatego w DevOps triumfują również języki pozwalające budować tą wymaganą infrastrukturę, jak np. Terraform.
A jeśli do tego dodamy, że praca jest skomplikowana i wymaga rozwiązywania pojawiających się problemów zespołowo, to okaże się, że konieczne jest użycie narzędzi pozwalających na sprawną organizację pracy. Na szczęście w DevOps nie stosuje się typowego gigantycznego narzędzia do dokumentowania pracy. Zamiast tego wybiera się bardziej intuicyjne metody jak Kanban, czy Jira Boards. Łatwiej przecież zamknąć sprawę przekładając karteczkę z części „Working on” do części „Done”, niż zamknąć ticket wypełniając dziesiątki nikomu do niczego niepotrzebnych pól.
Nie ma co ukrywać – żadne narzędzie nie ogarnie pracy, jeśli ludzie nie chcą współpracować, a żaden Project Manager zwany tu często Scrum Masterem nie zrozumie o co w tym chodzi, jeśli sam nie jest doświadczonym DevOps inżynierem. Dlatego koniec końców cała odpowiedzialność i tak spada na specjalistów technicznych, którym mówi się, że pracują w modelu „shared responsibility”. I coś w tym jest! Zespoły DevOpsowe z założenia mają być bardziej otwarte i komunikatywne. Błąd jest po prostu naturalnym krokiem w kierunku zdobywania doświadczenia, dlatego , mimo konieczności ciągłej nauki, poznawania nieznanych technologii, pracy w intensywnie zmieniającym się środowisku, DevOps daje poczucie pracy w całkiem innej kulturze. Kulturze wzajemnego zrozumienia, otwartości, komunikacji – a to ważne elementy redukujące charakteryzujące dobre stanowisko pracy.
2022-09-19
Azure Monitor pozwala na konfigurację alertów, które zostaną wyzwolone w przypadku zwiększonego wykorzystania zasobów wybranego obiektu infrastruktury, np. przeciążonego CPU, dysku sieci, ale także w oparciu o przekroczenie licznika pewnych zdarzeń, jak np. liczba nieudanych logowań w określonym czasie. Poniżej możesz zobaczyć, jak stworzyć taki alert przy pomocy powershella.
Na początek należy się zalogować do Azure i w razie potrzeby wybrać subskrypcję:
Connect-AZAccount
$subscription_name = 'XXX enter subscription name here XXX'
Select-AzSubscription -SubscriptionName "$subscription_name" | Out-Null
Przyda się też kilka zmiennych przechowujących pomocnicze dane:
$action_group_name = 'DBAADMIN' # limit 12 characters
$emails = ('one@example.com', 'two@example.com')
$description = "Please have a look at this issue!"
Teraz pora na zdefiniowanie kilku metryk. Dla własnej wygody robię to poprzez zdefiniowanie listy słowników:
$metric_alerts = @()
$condition = @{
'metric_name' = 'CPU Credits Consumed';
'threshold' = 80;
'window_size' = New-TimeSpan -Minutes 5;
'frequency' = New-TimeSpan -Minutes 1;
'aggregation' = 'Average';
'severity' = 3
}
$metric_alerts += $condition
$condition = @{
'metric_name' = 'CPU Credits Consumed';
'threshold' = 90;
'window_size' = New-TimeSpan -Minutes 5;
'aggregation' = 'Average';
'frequency' = New-TimeSpan -Minutes 1;
'severity' = 3
}
$metric_alerts += $condition
Czytaj dalej »
2022-08-31
Ceny prądu idą w górę, bo jakoś w dół nie chcą chodzić. Tymczasem, jak się już liźnie bakcyla Linuxa, to chciałoby się pewne rzeczy w domu poatuomatyzować, a więc urządzenie musi być cały czas włączone.
Dlatego do takich celów można przeznaczyć urządzenie Raspberry Pi, które oprócz pełnienia funkcji serwera SAMBA, FTP, WWW, może pracować jako serwer multimediów. Istnieją gotowe dystrybucje do obsługi Raspberry Pi jako serwera mediów (np. LibreELEC https://libreelec.tv/), ale wiele rzeczy jesteśmy w stanie skonfigurować korzystajc ze standardowego systemu Rasbian. Może czasami jest trochę trudniej, więcej trzeba się napisać albo naklikać, ale sie da.
Nie będę powtarzał dobrych instrukcji, ale chętnie na nie wskażę:
A dlaczego podaję aż tyle adresów? Bo, jak to bywa w open source, coś czasami zadziała, a czasami nie zadziała. W takim przypadku warto spróbować metody z innej strony. I najważniejsze – nie zrażać się!
2022-08-20
Pozwól, że nie będę tłumaczył skąd bierze się problem wraparound w PostgreSQL. Faktem jest jednak, że śpi się lepiej, kiedy masz świadomość, że taki problem Ci nie zagraża. Jak więc sprawdzić, czy jeszcze daleko do zderzenia z wraparound?
Oto query, które można uruchomić na bazie, żeby sprawdzić, co się dzieje z identyfikatorami transakcji:
SELECT
datname,
age(datfrozenxid) AS frozen_xid_age,
ROUND(
100 *(
age(datfrozenxid)/ 2146483647.0 :: float
)
) consumed_txid_pct,
current_setting('autovacuum_freeze_max_age'):: int - age(datfrozenxid) AS remaining_aggressive_vacuum
FROM
pg_database
WHERE
datname NOT IN (
'cloudsqladmin', 'template0', 'template1'
);
Query pochodzi z https://cloud.google.com/blog/products/databases/how-to-accelerate-transaction-id-freezing-in-cloud-sql-for-postgresql
Oj ciekawe obliczenia się tu dzieją:
- Każda baza przechowuje w swoich metadanych datfrozenxid – jest to identyfikator ostatniej transakcji, jaka została zamrożona. Jeśli ten numer jest stosunkowo blisko numeru bieżącej transakcji txid_current(), to dobrze – do przepełnienia mamy daleką drogę 🙂
- Ponieważ maksymalna liczba transakcji to 2^31, to można łatwo policzyć procent drogi do przepełnienia licznika transakcji, co dzieje się w drugiej kolumnie tego zapytania
- Można wreszcie wyznaczyć, ile jeszcze transakcji zostało do uruchomienia agresywnego autovacuum. Wystarczy do parametru autovacuum_freeze_max_age odjąć wiek datfrozenxid. Co istotne – odejmujemy wiek (age), a nie sam numer transakcji.
Zdarza sie, że adminom myli się wiek z numerem transakcji. Pomocne może być pamiętanie o następującej równości:
age(datfrozenxid) = txid_current() - datforzenxid
Ogólnie rzecz ujmując powinniśmy unikać operacji obliczeniowych na identyfikatorach transakcji, bo po wraparound ta matematyka może już nie działać, ale przynajmniej w początkowym etapie działania bazy (przed pierwszym przekręceniem licznika transakcji, wyniki powinny być intuicyjne. Można nawet pokusić się o sprawdzenie, czy age() zwraca rzeczywiście wynik odejmowania wspomnianych wartości:
dvdrental=# SELECT
datname,
txid_current(),
datfrozenxid, age(datfrozenxid),
txid_current() - datfrozenxid::text::bigint AS age_calc
FROM pg_database;
datname | txid_current | datfrozenxid | age | age_calc
-----------+--------------+--------------+------+----------
postgres | 1847 | 1596 | 251 | 251
dvdrental | 1847 | 1826 | 21 | 21
template1 | 1847 | 726 | 1121 | 1121
template0 | 1847 | 726 | 1121 | 1121
(4 rows)
Widać, że age() zwraca wynik odejmowania txid_current() – datfrozenxid
Zapobiegliwy admin może więc sobie śledzić wyniki pierwszego z zaprezentowanych tu zapytań i w miarę możliwości… spać spokojnie
2022-08-10
Błąd pojawia się przy poleceniu
pg_dump "host=... port=5432 dbname=... user=... password=... sslmode=require" -s -O > db_schema.sql
Rzeczywiście pg_dump był dość stary – 9.2.24, a serwer – też nie najnowszy – 11.16
Na serwerze było jednak zainstalowanych więcej wersji narzędzi Postgresa:
find / -name pg_dump -type f 2>/dev/null
Poz znalezieniu odpowiedniej wersji, można już odwołać się do konkretnej wersji pg_dump:
/usr/psql-11/pg_dump "host=... port=5432 dbname=... user=... password=... sslmode=require" -s -O > db_schema.sql
2022-07-11
Co jest najprzyjemniejsze po całym dniu pracy? Dźwięk zamykanej klapki laptopa. Pyk i masz wolne. Ufff
Ale co wtedy dzieje się na systemie? To zależy od tego jak jest skonfigurowane zdarzenie Lid closure.
Na moim ulubionym Ubuntu chcę, aby po zamknięciu klapki, system się zhibernował. Oto, co należy zrobić, żeby system się hibernował po zamknięciu laptopa.
- Najpierw sprawdzamy, czy hibernacja w ogóle działa. Sprawdzisz to poleceniem
sudo systemctl hibernate
- Po ponownym włączeniu można prześledzić, co odbiło się w logach:
sudo cat /var/log/syslog | grep "hibernation"
Powinno się tu udać wypatrzyć między innymi zdarzenia hibernation entry i hibernation exit
- teraz pozostaje konfiguracja zdarzenia „zamykania klapki laptopa”. Otwórz plik /etc/systemd/logind.conf
sudo vim /etc/systemd/logind.conf
Tutaj trzeba poszukać linijek
HandleLidSwitch=hibernate
HandleLidSwitchExternalPower=hibernate
HandleLidSwitch odpowiada za zdefiniowanie akcji, która ma być wykonana po zamknięciu klapki, gdy komputer nie jest podłączony do ładowarki, a HandleLidSwitchExternalPower odpowiada za tą samą sytuację, gdy komputer jest podłączony do ładowarki. U mnie obie akcje są skonfigurowane na hibernate.
- Po zapisaniu pliku należy zrestartować usługę systemd-login:
sudo systemctl restart systemd-logind.service
- Właściwie już można zamknąć klapkę, poczekać, otworzyć, zalogować się i zajrzeć do pliku /var/log/syslog, żeby upewnić się, czy hibernacja została rzeczywiście wykonana:
sudo cat /var/log/syslog | grep "hibernation"
- Jeśli nie, to spróbuj jeszcze zrestartować komputer. Koniec końców powinno zadziałać
