15 grudnia 2020

AWS re:Invent 2020 i redefinicja wysokiej dostępności dla data center

Kiedy zastanawiamy się nad pojęciem wysokiej dostępności (ang. high availability) w systemach informatycznych - o ile w ogóle niektórzy zastanawiają się - to warto nadmienić tutaj o ważnej nowości, którą podzielił się w ostatnich dniach Amazon w ramach konferencji AWS re:Invent 2020. Ten wpis to rozważania nad wysoką dostępnością w skrócie HA, jak możemy ją zdefiniować, jakie miary ją definiują i jakie techniczne zagadki nas czekają, kiedy mówimy, że "chcemy wdrożyć HA".


Wprowadzenie do HA

Wysoką dostępnością określamy stan systemu, kiedy jego funkcjonalności biznesowe, czyli te z punktu widzenia użytkownika końcowego w całości są dostępne do użycia. W języku polskim określa się to nawet skrótem SWN (system wysokiej niezawodności), z którym spotkałem się rzadziej niżeli przyjętym skrótem HA. Zasadniczo nie wszyscy rozumieją, że nie chodzi tutaj o dostępność wszystkich komponentów systemu, bo nie zawsze klikanie np: ikonki Like jest kluczowe dla biznesu. Dla jednego (patrz: Facebook) to core biznes, dla innego np: wirtualnej galerii sztuki to po prostu dodatek. Z tego też banalnego punktu widzenia, posiadanie wysokiej dostępności to sprawa zależna od core biznesu. 

Na pewno nie można dyskutować o płynności HA, w niektórych bardzo specyficznych dziedzinach t.j. medycyna, lotnictwo, obronność, przemysł kosmiczny, sterowanie ruchem, autonomiczne pojazdy, roboty przemysłowe i wiele innych. Jak widać, są zastosowania, gdzie warto nieco przedefiniować podejście do wysokiej dostępności. A może po prostu zastosować HA zgodnie z obowiązującymi normami :-)

Wydaje się niektórym młodszym przedstawicielom IT, że HA to ostatni nabytek branży IT i to tutaj tak dba się o wysoką dostępność. Otóż, założenie to jest obarczone błędem, bo HA również towarzyszyło pierwszym konstruktorom z różnych dziedzin np: w motoryzacji - silników, w przemyśle kosmicznym - napędów rakiet, od którego zależy powodzenie misji załogowej. Widać po tych przykładach, że HA, to nie jest kilka zasad i koniec. Na prawdziwe HA składa się wiele detali -  szkoły inżynierskie, praktyka starszych inżynierów i szkolenie młodych adeptów sztuki, monitoring, audyty, testy chaosu, fuzzing, dzielenie się wiedzą, bezpieczeństwo z podejściami blue/red i stałą eksploracją branży, budowanie standardów i norm, zasady i higiena w miejscu pracy, dyskutowanie o wyzwaniach i dzielenie się wiedzą, posiadanie patentów, poddawanie testom obciążeniowym tego co wytwarzamy i wiele więcej różnych tematów. Tak, na HA składa się dość sporo doświadczenia ludzi z różnych działów, aby w końcu je jakoś zapisać. Warto zapisać, bo do momentu posiadania "wirtualnego SLA", nie wiemy z czym się technicznie mierzymy.

Tak przy okazji, kiedy lecicie samolotem tam też są komputery, których HA jest wyliczone i jest taka mini serwerownia, która zapewnia redundancję, kiedy zawiedzie sekacja A. Nasze życie ratuje wówczas sekcja B oraz dalsze reakcje zgodnie z procedurami pilotów. Jak zaufać autopilotowi w takiej sytuacji ? Otóż, SLA takiego zachowania zostało określone w normach i testy, awarie, incydenty, wypadki wykazały, że pewne rozwiązania działają sprawniej od innych. Tym samym, są znane kroki, które podwyższają HA działania samolotów. Ba, są instytucje, które piszą standardy, abyśmy w powietrzu czuli się zdecydowanie lepiej niżeli w powietrznym PKSie ;-) Nie jest to uwaga do tanich linii lotniczych - polubiłem je kiedyś i nawet dają dreszczyk emocji czasami, gratis.

Jak przedstawić HA w postaci mierzalnej metryki

Zapisanie formalnie jaki jest poziom wysokiej dostępności (ang. HA) w naszym systemem dobrze jeśli będzie odbywał się w sposób pół-automatyczny i bazował na wskaźniku umownym Service Level Agreement (ang. SLA, - pol. umowa o gwarantowanym poziomie świadczenia usług). Tutaj słowo wyjaśnienia, bo SLA dla nas samych może wydawać się żartem, ale nim nie jest. Jest za to prawdziwym przedsięwzięciem, postawieniem na nogi wielu działów w firmie, dzięki czemu każdy w swoim zespole zastanawia się przy okazji: co mógłby zrobić jutro lepiej? na co nie było być może czasu wczoraj. A może był czas, ale zarządzanie nim nie było efektywne? A może klient nie zapłacił za SLA na poziomie wyższym niżeli mamy obecnie? 

Takie i inne ważne pytania warto zadać sobie w zespole, aby powiedzieć np: mamy SLA na poziomie zmierzonym od miesiąca wynoszącym 99,999 % !!! No na pewno nie będzie nikomu wstyd, jeśli takie SLA posiada, bo podana wartość to zmierzona niedostępność systemu 5 minut na rok :-)


Czemu warto walczyć o więcej 9-tek w swoim SLA?

Tak, są firmy, które walczą o więcej dziewiątek w swoim umownym zapisie o dostępności SLA i uwierzcie tysiące ludzi dbają o to, aby po roku rozliczyć się sumiennie z tego. Tak, bo inżynieria a nie amatorka polega na tym, że jeśli zgadzamy się w zespole na SLA i umawiamy, że będzie to grało na poziomie X, to robimy jako inżynierowie wszystko, aby do tego doszło. 

Nie zawsze w zespole są inżynierowie z tytułami, lecz dobrze jeśli znajdzie się taki dla uzupełnienia ekipy ;-). Warto wiedzieć, że obecnie w branży IT są obecni ludzie po technikach, po filozofii i innych szkołach i branża bardzo szanuje każdego, bo brakuje zwyczajnie chętnych osób o otwartych umysłach do stałej nauki nowości IT. Zapewniam Was, że niekiedy nieinżynierowie mają więcej odwagi/energii/zamozaparcia do zrobienia HA na solidnym poziomie, niżeli tzw. "inżynierowie z petrobudowy" jak śpiewał kiedyś Kazik. Ta dygresja wynika z doświadczenia, a nie jest to obraza dla szeroko rozumianej inżynierii. Mam tutaj na myśli fakt, że nie jeden inżynier w karierze zawodowej spotkał młodzika, który robił coś i szybko uczył się, po czym jego poziom realizacji zadań przewyższył poziom oferowany przez inżyniera. To w tych czasach IT może być zgubne, jak szybko ludzie spoza branży są w stanie, przy odpowiedniej motywacji stać się ekspertami. Zapewne jest to kwestia urodzenia obok tabletu :-) albo z wrośniętym 9-tym bitem, hahaa. 

Tutaj znajdziecie kalkulacje dostępności dla SLA. Istnieją w sieci też kalkulatory online dla SLA, gdzie wpisując 9-tki zobaczymy jak bardzo dostępny powinien być system IT wg. określonego SLA. 

Wracając do tematu kolejnych 9-tek w SLA, warto powiedzieć, że niektórym firmom HA zwyczajnie się to opłaca. Np: weźmy pod uwagę Allegro.pl, czyli taki najbardziej namacalny przykład polecanego e-commerce w naszym kraju :-) Doceniam inżynierię, jaką tam mogłem poznać i współtworzyć. To jak Allegro.pl podchodzi o SLA to właśnie przykład powagi i odpowiedzialności, dojrzałości zespołowej, gdzie na końcu Pan Kowalski kupując żyrafkę w pacyfki wnuczce w prezencie, po prostu klika "Kup teraz" i np: mając podpiętą kartę kredytową, nie musi się martwić tym, czy towar dotrze na miejsce. Tak, towar dotrze, bo większa grupa dojrzałych inżynierów jest świadoma tego, jakie ma SLA i to motywuje ich do dostarczania radości klientom :-)

Szukając przykładów bardziej globalnych, które też mają w swoich celach dostarczanie radości klientom, skupię się na SLA firmy Amazon, bo ciekawostka jakiej się dowiedziałem może Was zmotywować do pracy nad własnym HA.

Jak bardzo AWS zwiększył wysoką dostępność na poziomie centrum danych?

Centrum danych (ang. data center) tzn. serwerownia to zestaw wielu serwerów, na których działają obliczenia oraz przez które przemieszczają się różne dane klientów ew. towarów. Budowanie DC jest to dość nowa dziedzina, która zapewnia zbudowanie centrum obliczeniowego na wymaganym poziomie. Okazuje się, że wymagania z roku na rok rosną. Nie jest prawdą, że serwerownie mają jedno łącze do internetu i radośnie sobie wszystko działa, bo admin Janek czuwa nad stabilnością. Nie te czasy minęły ok. 15 lat temu. Obecnie serwerownie to miejsca ze specjalnymi klimatyzatorami, szynami wielu kanałów zasilających, awaryjnych UPSów, agregatów awaryjnych, które napędzane silnikami diesla pozwalają przetrwać serwerom braki i niestabilności zasilania. Prawdą jest, że kupując miejsce w DC mamy zazwyczaj jasno określone zasady HA np: przez podanie SLA i zasad wspierania HA, albo na różne inne sposoby, które są często tajemnicą wewnętrzną danego centa danych. 

W tym roku Amazon w ramach konferencji podzielił się pewną architekturą, jaką chciałbym przedstawić tutaj i pokazał, jak fajnie przeskalować i uzyskać kolejną 9-tkę wysokiej dostępności, fizyczną architekturą wspierającą ten cel. 

Otóż, kiedy popatrzymy na typowy obraz DC i zapewnienia podtrzymania zasilania, mamy taki ogólny diagram:





Wszystko jest tutaj dość łatwo rozpoznawalne dla wprawnych oczu z infrastruktury :-) Dla pewności omówię: mamy zewnętrznego dostawcę prądu i awaryjny agregat prądotwórczy, do tego logikę przełączników, baterię akumulatorów. Kiedy dostawca prądu powie nie mam fazy, wówczas na chwilę przełączania na agregat działamy z banków energii, jakimi są akumulatory. Tak, agregat rozgrzewa się jak stary zbawiciel diesel :-) Wiadomo, dolewamy paliwa do diesla, to agregat działa, jeśli nie dolewamy, to ma to często kilka do kilkunastu godzin działać, aż naprawią trakcję elektryczną.

Wygląda dość racjonalnie i teraz zobaczcie, co zrobił Amazon:






Jak widać na pierwszy rzut oka 99.99997 % SLA - tak, to nie błąd po przecinku są cztery 9-tki i jedna 7-ka. Co daje niedostępność ich infrastruktury serwerowej na poziomie .....  9 sekund rocznie !!!!
Sprawdźcie sami na kalkulatorze SLA online
Brawo, dla ich zapału, innowacji i inżynierii - to jest mega dobry wskaźnik jakości.

Dodali drugi tor z agregatem prądotwórczym i silą z elektrowni :-) 
To ciekawe, a zapewne drogie rozwiązanie, ale to nie jest koniec. Amazon przede wszystkim uznał, że wszystkie podsystemy po drodze tzn. UPS, logika w sterownikach, agregaty oparte są też o software i jak wiadomo, software ma błędy :-) Idąc dalej tym tropem, uznali, że sami stworzą sobie oprogramowanie a docelowo hardware dla swoich serwerowni. I tutaj pewnie uznacie, że to koniec zabawy, bo zrobienie własnego racka (szafki na serwery) jest bardzo spoko, ale własny UPS, to ambitny produkt. 
Oto, jak prawdopodobnie mogło się to rozegrać w praktyce: inżynierowie teoretyczni spotkali praktyków, mieli wspólne rozmowy, zapewne poleciało kilka nieudanych prób i nagle, po wykonaniu jednego komponentu kompleksowo okazało się, że działa tak jak chcemy i mamy do niego testy. 
Jeśli nasi testerzy wiedzą jak to działa i gwarantują nasze standardy jakości, to zaczyna się nieźle. 

Suma podwyższonych standardów jakości działów w Amazon, spowodowała, że te mniejsze SLA na poziomie poszczególnych zespołów wytworzyły wartość globalną jaką jest podwyższenie HA w produkcie AWS. Tak, przerabiali też hardware, ale jak widać, inaczej się nie da - tzn. nikt nie podzielił się taką wiedzą, jak to realnie zrobić inaczej. 
Coś, co widać i warto wspomnieć: Amazon uzyskał redundancję w DC, rozdzielając podsystem podtrzymania zasilania dla dwóch torów zasilania, które są w ich szafach z serwerami. Bo wiedzą, że przełączanie zasilania to też ryzyko i tym samym wypadki na tej linii mają z głowy. Okazuje się, że to dość wrażliwa sprawa :-) i wiem też z praktyki, że bardzo newralgiczna dla ludzi z utrzymania infrastruktury z wysokim HA.

Uznaję tą prezentację "Infrastructure Keynote" za lekcję, że jeśli zespół otrzymuje ambitne i czasami niemożliwe wyzwanie, wówczas odpowiednia ilość PoC, burzy mózgów, wiedzy, radości jako pozytywny miks, dają wartość biznesową innym. Tak, znam to uczucie - fajnie jest uczestniczyć w takim procesie twórczym ;-)

Wprowadzenie HA często niweluje tzw. jeden punkt awarii (ang. Single Point of Failure), pozwala zapewnić większą redundancję (ang. redundancy), czyli odporność na wymieniony SPoF. Z tym wiąże się często obserwacja i monitorowanie (ang. abservability and monitoring). Tak się składa, że świetnie się to wpisuje w filozofię DevOps, którą opisuję tutaj. Stosuję ją na co dzień w pracy i widzę, że bywa przekonująca dla wielu inżynierów :-) Bardzo pożądaną konsekwencją podwyższonego SLA jest też spadek zgłoszeń technicznych do działu kontaktu z klientami. Same plusy - tak, ale wiemy, że to inwestycja, która przenosi poziom organizacji na wyższy status. Nie wszystkich stać, ale Ci, którzy wdrożyli liczą pozytywne efekty dość szybko.

Jeśli macie jakieś przemyślenia związane z budowaniem większej dostępności w IT, napiszcie w komentarzach. Chętnie poznam Wasze punkty widzenia.


 




1 listopada 2020

Teachable Machine - Machine Learning to takie proste !

 Teachable Machine to projekt tworzony m.in. przez Google, który ułatwia wejście w podstawy uczenia maszynowego (ang. Machine Learning) poprzez praktykę. Tak wiele kroków należy uczynić, aby zrozumieć w praktyce Machine Learning, podstawy matematyczne, typowe algorytmy, algorytmy pozwalające na uzyskanie wysokiej skuteczności per różne dziedziny, frameowrki i programowanie, trenowanie modeli, dopieszczanie modeli, zapewnienie wlaściwych zbiorów danych do trenowania, itd. Jak widać z potoku pojęć, jest kilka tematów, które warto poznać, aby zrozumieć ML :-) 

Jednak poznanie Machine Learning nie musi być wcale takie trudne, kiedy mamy odpowiednie oparte o interfejs wizualny narzędzia. Oto docieramy do projektu Teachable Machine, dzięki któremu wytrenujemy rozpoznawanie różnych stanów/przedmiotów/obiektów w kilka minut. Sprawdźcie sami, bo tak banalny interfejs pokazuje, że problemy klasyfikacji nie są wcale trudne do zrozumienia w podstawach ML

To co zobaczmy - po kliknięciu w link - to przyjazny interfejs, który pozwala na podłączenie się z przeglądarki do kamerki lub upload obrazków dla poszczególnych klas służących do klasyfikacji.

 

Dzięki takiej sprytnej koncepcji możemy zrobić modele, wytrenować w locie nasz model i oglądać rezultaty w czasie rzeczywistym np: z podłączonej do laptopa kamerki.


Projekt nie ogranicza nas za bardzo, jeśli chcemy użyć wyobraźni to jest jak zawsze dozwolone ;-) W związku z tym wyjściem może być mowa lub dźwięk zależnie od ścieżki klasyfikacji.

Zachęcam do pokazania tego narzędzia dzieciom, bo jest to jak mi się wydaje najbardziej praktyczny sposób na odpowiedź dziecku na podstawowe pytanie: "co to jest machine learning?". Zapewniam Was, że nie zawsze odpowiedź na to pytanie udaje się znaleźć łatwo, stąd dzielę się tym znaleziskiem, być może wzmocnicie pojęcie ML u przyszłych pokoleń wynalazców ;-).

Więcej przykładów i sugestii do nauki Machine Learning z Teachable Machine przez zabawę możecie też wyszukać na YT, np:  


Jeśli udało Wam się ułożyć jakąś ciekawą klasyfikację, dajcie znać w komentarzach.

19 października 2020

Valgrind - pomaga wyszukać wycieki pamięci w programach

Chwilę pomyślałem sobie dzisiaj o problemach jakie mogą mieć urządzenia wbudowane z oprogramowaniem i przyszła mi taka myśl: 

Ciekawe, czy zależnie od języka programowania w standardzie możemy dostawać wycieki pamięci lub nie?

Z punktu widzenia różnych znanych mi systemów w urządzeniach mobilnych zastanawia mnie słabe rozwiązanie tego problemu - tzn. klikanie zwolnij zaalokowaną pamięć telefonu na żądanie. Inny wariant, to dedykowane programy z klasy "odśmiecacze pamięci", czyli dedykowane oprogramowanie, którego celem jest przegląd wszelkich niezwolnionych bloków i za zgodą usera próba zwolnienia. Brzmi znajomo, może Twój telefon z Androidem też przymula po otwarciu kilku aplikacji (nie koniecznie gier) ... i dopiero restart naprawia sprawę. Cóż, może mamy tam do czynienia z tzw. wyciekiem pamięci operacyjnej. Koncept nieskomplikowany do sprawdzenia na prostym przykładzie. 


Wprowadzenie do wycieków pamięci

Wyciek pamięci (ang. memory leak) to zaalokowanie pamięci w systemie operacyjnym przez program, który nie zwalania pamięci po zakończeniu swojego działania. 

Wszystko fajnie, kiedy bawimy się telefonem i po np: tygodniu działania zaczyna zamulać, robimy restart i działa dalej. Inaczej sprawa się ma na rynku np: serwerów, czy sprzętu ratującego życie, medycznego, diagnostycznego, kalibracyjnego. Są branże, gdzie wycieki pamięci to nie jest norma a poważny błąd. Każdy bajt wykradziony z puli w takich systemach wbudowanych, to proszenie się o zawieszenie systemu / programu / procesu, czyli o niestandardową awarię.

Nie jest tylko tak, że wycieki pamięci generują programiści danego softu. Mogą istnieć ukryte wycieki pamięci, które generują zewnętrzne bibioteki lub biblioteki współdzielone lub systemowe. Ta klasa błędów posiada dość szeroki zasięg ze względu na magię używania dwóch podstawowych instrukcji niższego poziomu w jężyka programowania t.j. C dobrze znanych. Są to:

 - alloc / malloc / calloc / tallloc i pochodne - rezerwują pamięć w programie dla zmiennej

- free i pochodne - zwalniają przydzieloną pamięć (po podaniu zmiennej z przydziału pamięci jako argumentu) 

Właściwie to chodzi tutaj o fakt, że nie wywołuje się FREE tam gdzie zachodzi *ALLOC. Niby takie proste w opisie a do osiągnięcia nirvany jest sporo kombinacji i pracy ;-)


Valgrind - ratunek na wycieki pamięci w oprogramowaniu

Na szczęście w fazie tworzenia oprogramowania, debugowania i testowania, jesteśmy w stanie sprawdzić jak zachowuje się oprogramowanie i dokonać rozpoznania wycieków pamięci. Narzędziem najpopularniejszym na rynku otwartego oprogramowania jest Valgrind 




Narzędzie to doczekało się dojrzałej wersji i bardzo bogatego portfolio, jeśli chodzi o wspierane architektury.

Valgrind obejmuje obecnie siedem narzędzi o jakości produkcyjnej: 
- detektor błędów pamięci 
- dwa detektory błędów wątków 
- pamięć podręczną i profiler predykcji rozgałęzień 
- wykres wywołań generujący pamięć podręczną 
- profiler przewidywania rozgałęzień 
- dwa różne profilery sterty. 
Zawiera również eksperymentalny generator podstawowych wektorów blokowych SimPoint. 
Działa na następujących platformach: X86 / Linux, AMD64 / Linux, ARM / Linux, ARM64 / Linux, PPC32 / Linux, PPC64 / Linux, PPC64LE / Linux, S390X / Linux, MIPS32 / Linux, MIPS64 / Linux, X86 / Solaris , AMD64 / Solaris, ARM / Android (2.3.x i nowsze), ARM64 / Android, X86 / Android (4.0 i nowsze), MIPS32 / Android, X86 / Darwin i AMD64 / Darwin (Mac OS X 10.12).

W Ubuntu możemy zainstalować narzędzie valgrind z takiego onelinera:

$ snap install valgrind  --classic



Test dwóch znanych języków programowania - Python i Golang - na wycieki pamięci w najprostszym programie

Wracam tutaj do założenia mojego wpisu. Mamy dwa bardzo popularne dzisiaj języki programowania: Python i Golang, którymi posługuję się biegle na codzień. Pomyślałem, spróbuję napisać jednolinijkowca i zobaczymy, czy valgrind coś wykryje :-) Poniżej zrzut z testu i rezultaty:


Program w Python + valgrind


$ cat memleaks_test.py 
print("a" * 255)

$ python3 memleaks_test.py 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Ok, odpalmy teraz z badaniem wycieków pamięci i co widzimy:

....
==19177== Invalid read of size 4
==19177==    at 0x5139AE: PyGrammar_RemoveAccelerators (in /usr/bin/python3.8)
==19177==    by 0x67EE59: Py_FinalizeEx (in /usr/bin/python3.8)
==19177==    by 0x6B614C: Py_RunMain (in /usr/bin/python3.8)
==19177==    by 0x6B63BC: Py_BytesMain (in /usr/bin/python3.8)
==19177==    by 0x4C890B2: (below main) (libc-start.c:308)
==19177==  Address 0x51f0020 is 384 bytes inside a block of size 732 free'd
==19177==    at 0x4A39078: free (vg_replace_malloc.c:538)
==19177==    by 0x51ACB8: PyGrammar_AddAccelerators (in /usr/bin/python3.8)
==19177==    by 0x5FD6C4: PyParser_New (in /usr/bin/python3.8)
==19177==    by 0x517293: ??? (in /usr/bin/python3.8)
==19177==    by 0x67BA7A: PyParser_ASTFromStringObject (in /usr/bin/python3.8)
==19177==    by 0x67BEFD: PyRun_StringFlags (in /usr/bin/python3.8)
==19177==    by 0x600581: ??? (in /usr/bin/python3.8)
==19177==    by 0x5C4D7F: ??? (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x5F7145: _PyFunction_Vectorcall (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x569559: _PyEval_EvalCodeWithName (in /usr/bin/python3.8)
==19177==  Block was alloc'd at
==19177==    at 0x4A37ECB: malloc (vg_replace_malloc.c:307)
==19177==    by 0x51ACCF: PyGrammar_AddAccelerators (in /usr/bin/python3.8)
==19177==    by 0x5FD6C4: PyParser_New (in /usr/bin/python3.8)
==19177==    by 0x517293: ??? (in /usr/bin/python3.8)
==19177==    by 0x67BA7A: PyParser_ASTFromStringObject (in /usr/bin/python3.8)
==19177==    by 0x67BEFD: PyRun_StringFlags (in /usr/bin/python3.8)
==19177==    by 0x600581: ??? (in /usr/bin/python3.8)
==19177==    by 0x5C4D7F: ??? (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x5F7145: _PyFunction_Vectorcall (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x569559: _PyEval_EvalCodeWithName (in /usr/bin/python3.8)
==19177== 
==19177== 
==19177== HEAP SUMMARY:
==19177==     in use at exit: 301,190 bytes in 135 blocks
==19177==   total heap usage: 2,186 allocs, 2,051 frees, 3,158,779 bytes allocated
==19177== 
==19177== LEAK SUMMARY:
==19177==    definitely lost: 0 bytes in 0 blocks
==19177==    indirectly lost: 0 bytes in 0 blocks
==19177==      possibly lost: 1,632 bytes in 3 blocks
==19177==    still reachable: 299,558 bytes in 132 blocks
==19177==         suppressed: 0 bytes in 0 blocks
==19177== Rerun with --leak-check=full to see details of leaked memory
==19177== 
==19177== Use --track-origins=yes to see where uninitialised values come from
==19177== For lists of detected and suppressed errors, rerun with: -s
==19177== ERROR SUMMARY: 1106 errors from 128 contexts (suppressed: 0 from 0)

Kilkaset bajtów program pożarł ;-) a to nowina dla wszystkich milionów użytkowników języka Pytohn :-) Polecam prztestować bardziej skomplikowane programy oraz serwery aplikacji.



Program w Golang + valgrind


$ cat main.go 
package main

import "fmt"
import "strings"

func main() {
fmt.Println(strings.Repeat("a", 255))
}


$ go build main.go 
$ ./main 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa


Program w GOlangu robi dosłownie to samo i badamy go przy pomocy valgrind:


==19372== Conditional jump or move depends on uninitialised value(s)
==19372==    at 0x40C4FD: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1152)
==19372== 
==19372== Conditional jump or move depends on uninitialised value(s)
==19372==    at 0x40C4B1: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1136)
==19372==    by 0x4474A8: runtime.growslice (/snap/go/6633/src/runtime/slice.go:230)
==19372==    by 0x43593E: runtime.allgadd (/snap/go/6633/src/runtime/proc.go:473)
==19372==    by 0x43D1F8: runtime.newproc1 (/snap/go/6633/src/runtime/proc.go:3572)
==19372==    by 0x45DBD2: runtime.newproc.func1 (/snap/go/6633/src/runtime/proc.go:3528)
==19372==    by 0x461605: runtime.systemstack (/snap/go/6633/src/runtime/asm_amd64.s:370)
==19372==    by 0x43745F: ??? (<autogenerated>:1)
==19372== 
==19372== Conditional jump or move depends on uninitialised value(s)
==19372==    at 0x40C4FD: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1152)
==19372==    by 0x4474A8: runtime.growslice (/snap/go/6633/src/runtime/slice.go:230)
==19372==    by 0x43593E: runtime.allgadd (/snap/go/6633/src/runtime/proc.go:473)
==19372==    by 0x43D1F8: runtime.newproc1 (/snap/go/6633/src/runtime/proc.go:3572)
==19372==    by 0x45DBD2: runtime.newproc.func1 (/snap/go/6633/src/runtime/proc.go:3528)
==19372==    by 0x461605: runtime.systemstack (/snap/go/6633/src/runtime/asm_amd64.s:370)
==19372==    by 0x43745F: ??? (<autogenerated>:1)
==19372== 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
==19372== 
==19372== HEAP SUMMARY:
==19372==     in use at exit: 0 bytes in 0 blocks
==19372==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==19372== 
==19372== All heap blocks were freed -- no leaks are possible
==19372== 
==19372== Use --track-origins=yes to see where uninitialised values come from
==19372== For lists of detected and suppressed errors, rerun with: -s
==19372== ERROR SUMMARY: 3447 errors from 761 contexts (suppressed: 0 from 0)

... i ku naszemu zdziwieniu jednak GOlang nie ma wycieków pamięci na takim samym banalnym programie.



Podsumowanie

Bardzo ciekawa obserwacja pomyślałem sobie, jak łatwo przy pomocy valgrind znajdziemy wycieki pamięci. Szczególnie kiedy chciałbym coś napisać na urządzenie wbudowane, którego wielkość pamięci RAM to nie są GB a MB, przemyślę jednak w jakim języku napisać kod. 
Nie chciałbym wpaść w totalne błędne wnioski, że nie można tego robić w Pythonie i tylko w GOlang, gdyż może to być błąd mojej wersji i w kolejnej zostanie naprawiony. Oczywiście, tak błachy błąd dla jednych programistów jest powodem do kolejnych eksperymentów dla innych. 

W związku z tym zapraszam do wypowiedzi, jakie macie doświadczenia z valgrind? Z jakich ciekawych sytuacji wyratował Was ten tool w pracy zawodowej? 


7 października 2020

Porównanie systemów Continuous Integration & Deployment - automatyzacja pracy DevOps (1 z 2)

Z każdym kolejnym rokiem, kiedy obserwuję działania firm z sektora IT - i nie tylko - w rozwoju własnego stylu DevOps, jestem po prostu pod wrażeniem na ile sposobów można zaimplementować automatyzację CI / CD (ang. Continuous Integration / Continuous Deployment). Ważne jest to, że świadomość automatyzacji rozwiązań IT jest faktem na rynku i jeśli są firmy, które wykonują wiele prac manualnie, to najpewniej istnieją ostatnie miesiące. 

Nie znam obecnie architekta oprogramowania, czy lidera zespołu, który pozwoliłby sobie na ryzykowanie z instalacją, czy wdrażaniem rozwiązań metodą potocznie nazywaną "z palca". Biznesowi zależy na szybkim podnoszeniu się z awarii i wiadomo, kiedy mamy automaty na wielu poziomach systemu informatycznego, to odbudowanie fragmentów i całego systemu po awarii powinno zajmować sekundy, czy minuty a nie godziny! 

Dzięki obecnym dość powszechnym narzędziom DevOps z dziedziny CI i CD nie musimy zbyt wiele szukać, aby natknąć się na takie rozwiązania w sieci. Tym artykułem chciałbym wprowadzić Was w temat CI/CD i podzielić się moimi spostrzeżeniami z ponad 10 lat pracy z automatyzacją oprogramowania i systemów IT.


Automatyzacja pracy - DevOps w IT 

Jest takie słynne powiedzenie o backupowaniu, które można spokojnie sparafrazować i odnieść do CI/CD tzn. "ludzie w IT dzielą się na takich, którzy robią automaty lub takich, którzy będą je robili". Weryfikuje to każda awaria, czy niedostępność systemu i wnioski nasuwają się same: maszyny najlepiej wykonują powtarzalne zadania a ludzie niestety nie są w tym aż tak precyzyjni. Mam tutaj na myśli konkretną sytuację z IT, tzn. w zespole ludzie mogą robić testy z macierzami i odhaczaniem przetestowanych pozycji, mogą pilnować się na wiele sposobów podczas kodowania, mogą robić sobie grupowe przeglądy kodu, głaskać po główkach, przytakiwać do każdej linijki kodu i wiele innych dziwnych zjawisk. Jedno jest pewne, człowiek jest słaby w powtarzalnych czynnościach i zawsze zdarzyć się może jeden mały błąd/nieuwaga, który/która spowoduje awarię w przyszłości. 

Automatyzacja i zastosowanie ścieżek CI oraz CD broni ludzi w IT przed tzw. przyzwyczajeniami i to właśnie automatyzacja + czytelne zasady najlepiej pilnują jakości a nie tester, czy lider techniczny. Tak, wiem, znajdą się też liderzy i testerzy, którzy powiedzą, że testy eksploracyjne są niezbędne i jak najbardziej zgadzam się z tym. To co chcę przekazać, że każdy człowiek ma słabsze dni, w przeciwieństwie do testów automatycznych lub wdrożeń automatycznych.


Testowanie automatyczne - Continuous Integration

Jest to element, który powoduje, że mamy powtarzalną "gwarancję" jakości działania naszego kodu. Oczywiście, o ile testy są napisane zgodnie ze sztuką i pokrywają istotne linie, funkcje, klasy rozgałęzienia kodu. Jeśli mamy testy tylko do builderów a nie mamy testów dla głównych funkcjonalnych klas/ścieżek, wówczas nie mamy co mówić o testowaniu a o sztucznym pokrywaniu kodu testami. Tak zupełnie realnie, każdy zespół i lider projektu powinien znać założenia zasad w danym projekcie. Nie zawsze 50% pokrycia kodu to coś co daje nam zapewniania jakości. Z mojego doświadczenia wynika, że 50 % pokrycia kodu testami (jednostkowe + integracyjne) to dobry wynik, pod warunkiem, że testujemy istotne ścieżki używane na produkcji - odnośnie aplikacji internetowych. W przypadku urządzeń elektronicznych z tzw. firmware, pokuszę się o stwierdzenie, że 50% może okazać się zbyt słabym pokryciem, gdyż w urządzeniach np: (Internetu Rzeczy) dochodzą abstrakcje na innym poziomie np: działanie w trybie offline, bez dostępu do sieci, pojawiają się przerwania, które wymusza klient, warunki fizyczne t.j. temperatura pracy i wilgotność powodują zmianę zachowania w  działaniu, wrażliwość na linie zasilania, o ile nie ma drugiej linii lub akumulatora, maszyna stanów wdrożona dla trybu online i offline, jakość wykonania obudowy, metod fizycznej instalacji oraz lokalizacja urządzenia, itd. Jak widać jest wiele więcej prawdopodobnych zmian warunków normalnych pracy niżeli w przypadku aplikacji internetowej zainstalowanej gdzieś w chmurze obliczeniowej i podlegającej limitom zasobów, restartom i ew. przytkaniu łącz sieciowych.

Rola DevOps to taka rola, gdzie decydujemy się na to, co warto przetestować automatycznie a co półautomatycznie, co jest core biznesem, a co satelitą. W roli DevOps podchodzimy poważnie do każdego przypadku, aby nie pominąć takich, które pozornie nie są istotone. Dlatego też testowanie automatyczne i metodologie DevOps są tak silnie ze sobą zespojone. W poniższym porównaniu systemów CI / CD jest możliwych wiele scenariuszy testowania i zachęcam z tego miejsca do podnoszenia dyskusji o tym, jak i co warto testować w naszych projektach. Rozmawiajcie o tym w zespołach, jakie zasady przyjmujecie i jakie jesteście w stanie zaakceptować jako minimum. Tak, warto znać minimum, bo jeśli uznamy, że 100% pokrycia to jest to, co chcemy robić, musimy mieć na uwadze, że firma płaci za to, że pisanie testów trwa 80% czasu do kodu, który pisaliśmy w 10% czasu. Nie każda firma i nie każdy właściciel zrozumie to, że tak drogie jest dbanie o jakość. Nie chodzi - jak się domyślacie - dosłownie o zrozumienie tego czasu pracy wymaganego na testy, a o to, jak duże koszty generuje ten proces i jak niewiele osób posiadających firmy była wcześniej inżynierami oprogramowania, którzy sprawdzili w praktyce, co daje wysoka jakość. To trzeba poczuć na własnym podwórku, aby mówić, że coś kosztuje za dużo w IT i oczywiście świadomie wyważyć, czy na pewno 100% pokrycia testami to jest kierunek, w jakim firma może lub/i powinna podążać. 

Warto przypomnieć, że testowanie w IT odbywa się na wielu poziomach prac i wg. ideii DevOps oraz TDD to najpierw powstają testy a potem kod. Z praktyki wiem, że spora część ludzi nie chce lub nie może przestawić się na taki sposób pracy. Szkoda, bo jeśli powstaje na początku test, to łatwiej jest wyobrazić sobie z jakich artefaktów powinna składać się implementacja. Jak wiem od znajomych, niestety uczelnie w PL nie uczą tego na takim poziomie, aby człowiek to poczuł na własnej skórze, więc porażki jakie miewają firmy, to jest też koszt wdrożenia juniorów (absolwentów studiów). Tak, edukacja oparta o praktykę z ludźmi z branży ułatwiłaby dużo, ale jak wiemy na uczelni nie płacą tyle, aby ludzie praktykujący sztukę wysokiej jakości chcieli tam zdobywać chleb. Nie zamierzam tym zdaniem położyć ogólnika na całą edukację w PL, ale chciałbym zaznaczyć, że w branży IT w kilku miastach w PL edukowanie z praktycznej jakości wytwarzania oprogramowania jest na poziomie średnim. Wyjaśnię dlaczego tak twierdzę: na podstawie rozmów z ludźmi z branży IT i edukacji, na podstawie prac magisterkich, czy doktorskich, które czytam/przeglądam "do poduszki" od kilku lat. Obserwuję też rynek, zatrudniam ludzi do pracy i widzę, jaki poziom reprezentują absolwenci studiów a jaki ludzie, którzy rok lub więcej przepracowali w firmie developerskiej IT.

Wracając do testów na różnych poziomach - wyróżnić warto kilka podstawowych pojęć:

  • testy jednostkowe (modułowe)
  • testy integracyjne
  • testy systemowe
  • testy behawioralne BDD
  • testy wydajnościowe
  • testy end-to-end
  • testy dedykowane dla platform (mam na myśli platformy mobilne, smartfony, urządznia IoT)
Jak widzicie jest tak, że w testowaniu automatycznym jest co robić i oczywiście stąd często konieczność posiadania takiej roli - stanowiska pracy - w zespole DevOps. Z mojej praktyki jest to w tych czasach dość popularne, że zespół robi produkty a dedykowany tzw. tester automatyczny pisze kod automatów potwierdzających, że ścieżki główne w systemie mają pokrycie w automatach. 

Z takimi testami automatycznymi idą w parze testy po każdej zmianie, ew. tzw. night build, czyli testy odpalane nocą, w celu potwierdzenia, że integracja w systemie nie została zaburzona. To może mieć wielką moc, kiedy np: wiele zespołów pracuje nad różnymi domenami większego projektu i codziennie pojawiają się tysiące nowych linii kodu i testów do nich. Oczywiście, każdy zespół dba o swoją kontrolę jakości, ale nie zaszkodzi na pewno wszystkie nowe tagi z danego dnia zintegrować w takim night build, który rano wyśle raport tylko wtedy, kiedy nie udało się dokonać automatycznie integracji rozwiązań. Jest to dodatkowy automatyczny nadzorca pracy w rozproszonych zespołach nad większym produktem. 

Jak zdążyliście zauważyć, testowanie automatyczne to jest dziedzina w IT i jeden człowiek tego nie robi, a zaleca się w duchu DevOps wdrażanie zarówno do tego procesu wszystkich developerów. jak i wszystkich adminów oraz innych operatorów systemów np: ludzi z monitoringu. Znam kilka takich sukcesów w większych i mniejszych firmach, w których miałem okazję pracować. Rekomenduję zastosowanie podejścia DevOps - to się opłaca! 


Wdrażanie automatyczne - Continuous Deployment

Załóżmy, że mamy już nasze testy, wykonują się na CI, więc skoro zakodowaliśmy ficzer, to czas go wdrożyć! Oczywiście, nie zawsze jest tak różowo w projektach IT. Bywają chwile, że zanim zorientujemy się, jak firma w której jesteśmy wdraża, to zaczynamy szukać innej pracy. Oczywiście, nie chodzi tutaj o bunt, ale o trzymanie pewnego poziomu. Polecam zamiast zmieniać miejsce pracy, zaproponować i podjąć wyzwanie wdrożenia wdrażania kodu w sposób automatyczny.

Deployment, czyli wdrażanie kiedyś odbywało się w sposób dość banalny: e-mail lub ticket do admina, on na drugi dzień go znajdował w kolejce zadań i jeśli miał czas, wykonywał ręczne skrypty lub o ile był bardziej ogarnięty jakieś pół-automatyczne procedury wdrożeniowe. Te czasy na szczęście w większości firm się skończyły i nastała epoka otwartych API do narzędzi, które potrafią wdrożyć za nas kod w chmurze publicznej, prywatnej, na kubernetes lub on-premises. Nastały czasy PaaS, czyli platform jako usług, za które płacimy, ale mamy od nich gotowy zestaw narzędzi. Zależnie od tych narzędzi jedni budują specjalny kod do wdrożenia, inni tworzą dedykowane DSL (ang. Domain Specific Language), jeszcze inni tworzą pliki YAML, w celu opisania jak takie automatyczne wdrożenie powinno przebiegać.

Oczywiście jest tak, że wdrażanie automatyczne na produkcję, raczej warto nazwać od razu pół-automatycznym, bo często jest tak, że dopiero po wyrażeniu zgody kod na maszyny produkcyjne jest wdrażany. Oczywiście nie musi to dotyczyć maszyn w środowisku deweloperskim. 

Dobrą praktyką jest również stosowanie tzw. canary deployment, tzn. decydowanie na jaki procent klientów ew. pod jaki konkretnie ficzer ew. dla jakich userów ew. jakiej części świata kierujemy wdrożenie. Np: w Facebook mają tak, że Indie stanowią dla nich "piaskownicę" na produkcji i jest tam wdrażany kod produkcyjny jako pierwszy, o ile nie będzie zgłoszeń o awariach, następują wdrożenia na inne kontynenty. Jeśli chodzi o nasze rodzime biznesy, też potrafią sterować procentem ruchu, w ramach wdrożeń i np: na 5 ze 100-tu instancji usług puszczane jest wdrożenie, aby zaobserwować co się dzieje, po czym wdrażamy na kolejne 5, kolejne 10, 20 i 50, po czym, jeśli po kilku dniach nie ma żadnych wad, oznak błędogenności nowej wersji, przełączamy wdrożenie na 100%. Tak, to daje nam w branży IT wielki button zwany powrotem, w sytuacji rozwoju nieścisłości w nowych wersjach. Ten guzik nazywa się rollback i zdarzyło mi się nie kilka razy go użyć, aby nie wywołać regulaminowej awarii. Nie ma się co bać wycofać kodu z np: 5% maszyn na produkcji, kiedy widzimy możliwość poprawy jakości rozwiązania. 

Musicie sobie zdawać sprawę z tego, że przy nie ważne jak bardzo dużej ilości automatów i metryk chroniących nas przed awarią, zawsze to właściwa produkcja jest tym systemem docelowym, który jest używany przez klienta tak jak potrafi, t.j. go nauczyliśmy i czasami t.j. chciałby nas zaatakować. Tak, dobrze zdawać sobie sprawę, że w wielu przypadkach automaty ratują nas przed wielką wywałką produkcji, ale to człowiek na końcu w coś klika i jeśli DevOps, który wdraża nie zweryfikuje do końca, czy wdrożenie przebiega w sposób poprawny, to nikt za niego tego najpewniej nie zrobi. To jest też element odpowiedzialności w roli DevOps, której niektóre firmy się boją, bo jak można dać Januszowi dostęp do produkcji! Nie myślmy w ten sposób, bo Januszowi nie musimy dawać dostępu do produkcji, ale zestaw praktyk i narzędzi, aby mógł wdrażać etapami, po tym jak stwierdzi, że nie działa toto dobrze, aby Janusz mógł wycofać. Zaznaczę od razu, że nic nie mam do imienia Janusz, po prostu to takie polskie i popularne imię, którego użyłem dla przykładu. 

Kolosalną sprawą jest odpowiedzialność wdrażającego, więc często taką osobę w zespole uczy się codziennymi drobnymi wdrożeniami, buduje się z zespołem i szlifuje narzędzia do wdrożenia oraz wycofywania wdrożeń. Nie żyjemy w buszu, jeśli są jakieś "węże" w kodzie, to na pewno dobrze się ukrywają i wypełzną we wdrożeniu lub tuż po nim. Automatyczne wdrażanie oraz praktyki, jakie tworzymy w zespole w tym obszarze na pewno pozwolą ludziom z IT spokojniej spać ;-)

Słowo dodam jeszcze do tego, jak często wdrażać kod, bo możecie sobie pomyśleć, że najlepiej to jak wszystko jest ok, idealnie, działa na 101% i wszyscy klepnęli swoje taski. Cóż, wg. ideologii DevOps i znanych mi zwinnych praktych (ang. Agile), to tak naprawdę im częściej wdrażamy drobne zmiany, to nad nimi panujemy, więc zgodnie z zasadą "wdrażaj częściej, podnoś się szybciej" warto o tym wspomnieć, że jest to kwestia biznesu oraz wrażliwości na zmiany. 

Jak dla mnie warto przystosować się do zasady, że "jedyną stałą jest zmiana" i doprowadzić infrastrukturę IT do takiego stanu, aby klienci nie odczuwali efektów ubocznych wdrożeń. Nie tyle wiem, że to jest możliwe, ale potrafię takie architektury budować, dlatego rekomenduję podejście budowania wysokiej dostępności (ang. High availability) zamiast ściemniać, że może wdrożenia nocne ew. poranne nas uratują. 

Z mojego punktu widzenia, są biznesy, gdzie wydawać by się mogło, że nie da się zbyt tanio zbudować HA (t.j. przemysł medyczny, kosmiczny, górniczy, itp.) na wymaganym poziomie, ale praktyka pokazuje, że jeśli zbierze się zespół zgranych ludzi i będą motywowani do dokonywania niemożliwego, to "da się" osiągnąć wysokie HA, tam gdzie ludzie myślą, że jest to niemożliwe. Ba, nawet da się osiągnąć więcej tzn. podzielić się taką wiedzą ze społecznością OpenSource, a to w efekcie powoduje, że inne rozwiązania stają się niezawodne.

Jakie systemy CI / CD mamy obecnie na rynku?

Tutaj przychodzi mi na myśl porównanie systemów CI zrobione na wikipedii, które jest dość dużym uproszczeniem dostępnych narzędzi. Ze swojej strony chciałbym jednak podzielić się moimi prywatnymi spostrzeżeniami, które uzupełnią Waszą wiedzę. Postanowiłem, że w sposób opisowy opowiem o kilku znanych mi CI/CD z wymienieniem swoich spostrzeżeń n.t.

Wiele prezentowanych rozwiązań posiada wspólne cechy, które niosą nam ważną wartość - jeśli obecnie używasz zbyt drogiego lub wolnego CI / CD, bardzo prosto możesz zmigrować do innego. Zazwyczaj wystarczą zmiany w jednym pliku YAML, który definiuje kroki działania i po sprawie. 

Aspekt dość istotny w wielu systemach CI / CD, które mamy na rynku, to że większość oferuje nam darmową automatyzację! Tak, każdy w PL dba o to, aby wydać jak najmniej PLN, czyli mamy to co lubimy - żartuję. Jest tak wiele platform, że konkurencja "gryzie" wzajemnie i dochodzi do tego, że można w firmie używać latami za darmo CI/CD - bo firmy, które je robią dostają grube miliony od VC na tworzenie swoich rozwiązań. Tzn. żaden kowalski zużywający 1 CPU co kilka godzin nie jest dla większości straszny. Dochodzą do tego gracze z TOP 5 firm technologicznych, którzy dają za darmochę CI / CD, bo inaczej nie przyciągną klientów do innych usług, które oferują. Czyli CI / CD stały się takim wabikiem na inne usługi: konsultingowe, reklamowe, magazynowe, i inne. Tak, nie pozostaje nic innego jak tylko brać i działać ;-)

Przedstawię w przypadkowej kolejności systemy CI / CD, z którymi się spotkałem i otwieram tym samym dyskusję n.t. Bo jakby nie było, spędzamy jako osoby w roli DevOps tygodniowo godziny na automatyzacji pracy w jednym lub w kilku z tych systemów. Naszą nagrodą - za to, że automaty wykrywają wcześniej potencjalny problem lub awarię przed produkcją - jest fakt radości z podnoszenia kwalifikacji jako DevOps, zapewne wzrost wynagrodzenia, szacunek w branży i oczywiście powodzenie biznesu, bo jak to mawiał jeden gość "nie ryjemy do szuflady" ;-)


Kiedy dotarłeś już do tego miejsca to świetnie! - znasz już podstawy tematyczne do dalszej lektury. 

Składam w tym miejscu obietnicę, że w kolejnym odcinku z tej serii podzielę się z Tobą wiedzą o tym, co stanowi detale w temacie. Postanowiłem zacząć od rozgrzewki i okazało się, że art. byłby za długi z detalami ;-)


Już niebawem kolejny artykuł z tej serii:

Porównanie systemów Continuous Integration & Deployment - wybierz CI / CD dla działań DevOps (2 z 2)

  

20 sierpnia 2020

Ponad rok na Kali Linux z punktu widzenia 15 lat pracy na Ubuntu Linux

Kali Linux, jak każda dystrybucja bazująca na Ubuntu Linux, który z kolei bazuje na bazie Debian Linux to sprawa dość nieskomplikowana w codziennym użyciu dla DevOps, developerów i adminów. Linux kernel, jest tam aktualizowany, można używać pełnego zestawu narzędzi wizualnych np: gnome i to się spina bez bólu na desktopie. Nie zauważymy różnicy na desktopie w codziennym użytkowaniu.

 


Nie to jednak jest w Kali Linux fajne i praktyczne, że działa podobnie do Ubuntu Linux. Jak większość z was wie, Kali Linux stał się ulubioną dystrybucją: ludzi z gimnazjum, "hackjerów" ;-), white hackerów, testerów penetracyjnych,  red teamów i wielu innych profesji skoncentrowanych wokół bezpieczeństwa systemów i aplikacji w IT, ale też amatorów różnych rozrób i problematycznych sytuacji. 

To jest temat na odrębny wątek, jak ludzie - w tym dzieci - mogą uszkodzić coś lub wpaść w kłopoty, kiedy "przyhaczą" coś na Kali Linux. 

Musimy zdawać sobie sprawę, że z natury zawód związany z tzw. SECURITY w IT to ludzie często na tyle zaawansowani technicznie, że żarty to nie jest ich główne zajęcie a niesamowite analizy włamań/malware/trojanów/wirusów/skany sieci/diagnozy powłamaniowe/predykcje ryzyk/odkrywanie ukrytych otwartych portów i usług/szybkie i trafne decyzje. Szacunek! 

Natomiast, kiedy czasami czytam i słucham różnych opowieści, jak przysłowiowy Janusz "przyhaczył" dzięki Kali coś grubego ... ja tego nie popieram i tym wpisem nie zachęcam do takich działań. Chiałem to napisać, aby z pełną świadomością oznajmić, że jeśli używasz Kali Linux, to nie jest tak, że jesteś bezpieczny i niewidzialny. Po prostu masz w rękach narzędzia, którymi możesz też zrobić z wirtualnego problemu namacalny realny incydent. Tego nie popieram i ten wpis jest nie jest instrukcją użycia narzędzi a subiektywną opinią, którą przedstawiam w celach edukacyjnych. Bawicie się Kali Linux na własne ryzyko, wszelkie poniesione szkody, komplikacje, inne zdarzenia są wyłącznie Waszą odpowiedzialną decyzją. A za dzieci odpowiadają rodzice w większości cywilizowanych krajów.  

Jak pewnie większość z Was zdaje sobie sprawę, w Kali Linux mamy wielki potencjał do testów bezpieczeństwa. Tzn. są tam fantastycznie skatalogowane zestawy narzędzi do różnych typów działań w obszarze tzw. bezpieczeństwa IT. Oto lista kategorii, w których w Kali Linux możemy dotrzeć do profesjonalnych narzędzi pentesterskich tzn. otwartego oprogramowania, wolnego od licencji, dzięki któremu możemy wyszukiwać różne informacje, dane, błędy, naruszenia i wady systemów operacyjnych, protokołów oraz aplikacji.

Do czego ja używałem Kali Linux - wyłącznie do rozwiązywania na nim zadań w ramach tzw. konkursów CTF, czyli "capture the flag". Są to odbywające się weekendowo wyzwania dla zaawansowanych użytkowników komputerów, w których zagadki zaczynają się od banalnych binarnych trickach, poprzez rekonesans na gotowych wirtualnych maszynach, analizę obrazów i ukrytych w nich szyfrów, zagadnienia sieciowe, XSS, SQL Incection, wady serwerwów www, autorskie dekodowanie kart perforowanych i wiele na prawdę ambitnych zagadek  a kończą na odnajdywaniu przy pomocy dekompilacji kodu asemblera nieznanego procesora jakich instrukcji, które zawieszą kod programu :-)

Tak, około roku zabawy na takich konkursach potrafi wzmocnić umiejętności rozwiązywania "różnych" incydentów w IT. Spokojnie polecam dołączenie do zespołu lub indywidualne startowanie w konkursach CTF - co ciekawe, odkrywając flagę za każdym razem uczymy się czegoś nowego o IT. Tak, to zajęcie uczy tzw. szacunku do problemów zawodowych oraz postrzegania tego, co jest na prawdę ważne, wnikliwości i tego jak szybko jesteśmy w stanie nauczyć się np: nowego języka programowania w kilka godzin, aby móc zdebugować w nim quasi-program. 

Kali Linux to nie tyle system operacyjny do CTFów, ale przede wszystkich zwykły Linuxowy OS do codziennego użytku dla ludzi z branży IT. Chciałem w dalszej części skoncentrować się na jednym ciekawym przypadku, który rozgrzebałem technicznie i stał się na tyle podejrzany dla mnie w dystrybucji Kali Linux w odniesieniu do Ubuntu Linux, że zechciałem o nim wspomnieć.

Jakiś czas temu zrobiłem ciekawy switch i mając Ubuntu 20.04 LTS wykonałem niniejsze polecenia, które zamieniły mojego Ubuntu w Kali - to bardzo fajne tricki możliwe w Linuxowym świecie :-) 



Tak na marginesie: jak wiemy Windows zamieni się niebawem w Lindowsa i możliwe, że też jednym pstryczkiem, ale za tym stoi wielka maszyneria biznesowa, aby nie utrzymywać swojego dość wadliwego jądra. Tak mam na myśli M$, który porzuciłem ~20 lat temu w domu i pracy, co bardzo otworzyło mi oczy i nie to była dość trafiona decyzja. Tak, wiem Azure to już w większości Linux od wielu lat i M$ też wie jak kompilować jądro i dopisują swoje rzeczy do kernela ... ale ta firma nie robi nic bezinteresownie, bo każda firma z założenia zarabia. Nawet wtedy, kiedy musi porzucić swój plan budowy jądra systemu operacyjnego a bierze Linux Kernel z Open Source, pisząc wszem i wobec, że "my też to stworzyliśmy". I mają prawo tak rzec, bo commitują swoje zmiany do kernela LInuxa, ale jak wiemy, w tych czasach marketing może robić z takimi działaniami cuda.

Powracając do myśli przewodniej, jestem zadowolony z Kali Linux jako desktopowego Linuxa i polubiłem ten zestaw narzędzi do CTFów, którego używam czasami do rozwiązywania problem, które zdarzają się przy produkcji oprogramowania. Jedna sprawa mnie zmartwiła w wersji Kali 2020.3:

$ lsb_release -a

No LSB modules are available.

Distributor ID: Kali

Description: Kali GNU/Linux Rolling

Release: 2020.3

Codename: kali-rolling


Otóż po jakimś czasie - odtwarzalne na trzech różnych maszynach - pojawiły się nierozwiązywalne metodą "--fix-*" z apt-get konflikty, przy poleceniu standardowym aktualizacji paczek systemowych:

sudo apt-get upgrade

Wygląda to mniej więcej tak:

$ sudo apt-get upgrade 

Czytanie list pakietów... Gotowe

Budowanie drzewa zależności       

Odczyt informacji o stanie... Gotowe

Należy uruchomić "apt --fix-broken install", aby je naprawić.

Następujące pakiety mają niespełnione zależności:

 gnome-control-center : Wymaga: gnome-control-center-data (>= 1:3.36.4-1) ale 1:3.36.4-0ubuntu1 jest zainstalowany

 gnustep-base-runtime : Wymaga: libobjc4 (>= 4.2.1) ale nie jest zainstalowany

 libgnustep-base1.27 : Wymaga: libobjc4 (>= 4.6) ale nie jest zainstalowany

E: Niespełnione zależności. Proszę spróbować wykonać "apt --fix-broken install" bez pakietów (lub podać rozwiązanie).

i co najgorsze zachowuje się bardzo słabo w naprawie i skutki są dość słabe. Po kolei:

- wykonanie w/w apt'a z zalecanym "--fix-broken" powoduje, że nie może wykonać się do końca poprawnie, brakuje mu obrazka

$ sudo apt --fix-broken install

Czytanie list pakietów... Gotowe

Budowanie drzewa zależności       

Odczyt informacji o stanie... Gotowe

Naprawianie zależności... Gotowe

Następujące pakiety zostały zainstalowane automatycznie i nie są już więcej wymagane:

  cryptsetup-nuke-password efibootmgr finalrd fonts-wine gnome-control-center-faces gparted-common

  grub-efi-amd64-bin humanity-icon-theme kpeople-vcard libboost-filesystem1.67.0 libboost-system1.67.0

  libboost-thread1.67.0 libcapi20-3 libdb5.3:i386 libebml4v5 libfaudio0 libfprint-2-tod1

  libgsoap-2.8.91 libgtkmm-2.4-1v5 libgtkspell0 libhogweed5 libigdgmm11 libkaccounts1

  libkf5contacts-data libkf5contacts5 libkyotocabinet16v5 liblz1 libmatroska6v5 libmng2 libnettle7

  libnfsidmap2 libnumbertext-1.0-0 libnumbertext-data libopenshot-audio6 libopenshot16 libopenvdb7.0

  libpcre2-8-0:i386 libplacebo7 libpoppler82 libprotobuf-lite22 libprotobuf22 libqrcodegencpp1

  libqxp-0.0-0 libsrt1 libstaroffice-0.0-0 libstb0 libtokyocabinet9 libtsk13 libvkd3d1 libvolume-key1

  libwagon-http-shaded-java libwhisker2-perl libwine libzmf-0.0-0 node-normalize.css

  python-backports.functools-lru-cache python-bs4 python-html5lib python-lxml python-numpy

  python-soupsieve python-webencodings python3-ecdsa python3-entrypoints python3-pycryptodome rpcbind

  shim ssh-import-id ubuntu-mono wine64

Aby je usunąć należy użyć "sudo apt autoremove".

The following additional packages will be installed:

  gnome-control-center-data guile-2.2-libs inkscape libgc1 libgdl-3-5 libgdl-3-common libgsl25

  libgslcblas0 libgtkspell3-3-0 libmailutils7 libmariadb3 libobjc4 mailutils mailutils-common

  mariadb-common

Sugerowane pakiety:

  inkscape-tutorials libsvg-perl libxml-xql-perl pstoedit python3-uniconvertor gsl-ref-psdoc

  | gsl-doc-pdf | gsl-doc-info | gsl-ref-html mailutils-mh mailutils-doc

Polecane pakiety:

  python3-scour

Następujące pakiety zostaną USUNIĘTE:

  libgc1c2 libgsl23 libmailutils6

Zostaną zainstalowane następujące NOWE pakiety:

  libgc1 libgdl-3-5 libgdl-3-common libgsl25 libgtkspell3-3-0 libmailutils7 libmariadb3 libobjc4

  mariadb-common

Następujące pakiety zostaną zaktualizowane:

  gnome-control-center-data guile-2.2-libs inkscape libgslcblas0 mailutils mailutils-common

6 aktualizowanych, 9 nowo instalowanych, 3 usuwanych i 763 nieaktualizowanych.

841 nie w pełni zainstalowanych lub usuniętych.

Konieczne pobranie 0 B/28,4 MB archiwów.

Po tej operacji zostanie dodatkowo użyte 25,4 MB miejsca na dysku.

Kontynuować? [T/n] T

Konfigurowanie pakietu libgcc-s1:amd64 (10.2.0-9) ...

Konfigurowanie pakietu libseccomp2:amd64 (2.4.4-1) ...

(Odczytywanie bazy danych ... 647544 pliki i katalogi obecnie zainstalowane.)

Przygotowywanie do rozpakowania pakietu .../gnome-control-center-data_1%3a3.36.4-1_all.deb ...

Rozpakowywanie pakietu gnome-control-center-data (1:3.36.4-1) nad (1:3.36.4-0ubuntu1) ...

dpkg: błąd przetwarzania archiwum /var/cache/apt/archives/gnome-control-center-data_1%3a3.36.4-1_all.deb 

(--unpack):

 próba nadpisania "/usr/share/pixmaps/faces/bicycle.jpg", który istnieje także w pakiecie gnome-control-center-data

enter-faces 1:3.36.4-0ubuntu1

dpkg-deb: błąd: podproces wklej został zabity sygnałem (Przerwany potok)

- uruchamia się w nieskończoność appport raportujący te błędy, przez co syslog osiąga GB wielkości i zapycha dysk, dalej jest już wiadomo bardzo trudno pracować na systemie z 0 miejsca na partycji systemowej !

- problem jest słabo opisany w sieci i jedyny motyw na odzyskanie miejsca na dysku to usunięcie z /var/crash/ plików !!!


$ ll /var/crash/gnome-control-center-data.0.crash 

-rw------- 1 root whoopsie 386566 paź  9 17:42 /var/crash/gnome-control-center-data.0.crash

$ sudo rm /var/crash/gnome-control-center-data.0.crash 


Uważam, że to jest dość ważny aspekt, aby takie narzędzie jak apt działało poprawnie i tutaj w Kali Linux spotkałem się z mega blokadą, nie pomaga dist-upgrade, nie pomaga szukanie dziury w całym przy pomocy strace, kończy się tym, co kojarzę z RedHat sprzed 20 lat, tzn. chcesz mieć spełnione zależności, to sobie je spełnij sam :-) Rozumiem, że osoba która jest wydawca pakietu mogłaby mnie wspomóc w temacie, o ile to problem z pakietem - nie wydaje mi się, bo próbowałem też dpkg i efekt jest identyczny.

Inny drobny brak w distro Kali Linux - tak mogę to określić - to niedziałająca domyślna obsługa filesystemów takich jak vboxfs (chciałbym sobie na vagrancie i virtualbox zrobić testy), czy LUKS (chciałbym odczytywać szyfrowane wolumeny). Rozumiem, że to sobie mogę doinstalować, ale niespodzianką było dla mnie włożenie pendrive z zaszyfrowanymi danymi przy pomocy LUKS w Kali Linux nie skutkuje automontowaniem i pytaniem o hasło. W Ubuntu Linux takie rozwiązania działają z paczki. Tak, wiem Kali Linux nie do tego celu był stworzony i nie chcę się o to spierać :-) Nadmieniam tylko, że nie zawsze potrzebujemy specjalnej dystrybucji, która rozwiązuje nasze potrzeby. Twierdzę, że czysta (z linii LTS) wersja Ubuntu jest na tyle wytestowana przez userów i naprawiana na bieżąco przez devów, że o wiele prościej rozwiązuje się takie codzienne zagadki jak te z aptem opisane powyżej w Kali Linux.

Reasumując - polecam pomimo opisanych incydentów Kali Linux zaawansowanym użytkownikom i profesjonalistom, zniechęcam amatorów i noobów :-)

Ubuntu Linux po kilkunastu latach trenowania/testowania/używania/pracy/zabawy/odkrywania przedstawił mi się w wersji 20.04 LTS jako system dość dobrze ustabilizowany w codziennym użytkowaniu do pracy i w zastosowaniach  domowych. Polecam Ubuntu Linux, bo jeśli z Windows znane są Wam nadmiarowe programy ochronne, które musicie tam posiadać, bo trojan i wirus czeka, aby się zemścić - to w Ubuntu Linux firewalle, snorty, auditlogi są dość uproszczone i nie wyżerają 30% CPUs a pozwalają na bezpieczną pracę i zabawę również na desktopie.

17 lipca 2020

Kontenerowe systemy operacyjne - porównanie (Container OS)

Pamiętam, jak kiedyś stawiałem FreeBSD na maszynie i486 DX jako bramka do neostrady z 1 CPU. To była niezła przygoda, bo maszynka ta działała kilka lat bezawaryjnie, system na niej również. Tak, to był czysty przypadek :-), bo w serwerowniach normalnie nie zdarzają się takie "cuda" :-) Ponadto instalacja na każdej maszynie oddzielnie to byłaby zwykła robota głupiego. Minęło od opisywanego wyżej dzieła >18 lat i doczekaliśmy się dojrzałej konteneryzacji, całe szczęście dla utrzymania rozwiązań w IT. 


Kontenery

Kontenery szybko stały się niezbędną częścią nowoczesnych centrów danych. Kontenery można budować na dowolnej bazie z wielu podstaw systemu operacyjnego. 

W jaki sposób więc wybrać kontener?

W kontekście wdrażania kontenera kierownicy ds. rozwoju systemów muszą wiedzieć, które cechy i funkcje systemu operacyjnego są krytyczne dla wydawanych aplikacji i czy istnieją inne czynniki - takie jak łatwość zarządzania i elastyczność konfiguracji - które skłoniłyby organizację do wybrania jednego systemu operacyjnego zamiast wielu. Oczywiście łatwo utrzymuje się stan wiedzy inżynierów, jak i stack technologiczny jeśli systemy operacyjne w nim są liczone w kilka a nie kilkanaście.

Jak wypada porównanie różnych systemów operacyjnych pod względem funkcji i podstawowych funkcji? Jak te różnice wpływają na sposób, w jaki będą obsługiwać aplikacje? Oto podstawowe pytania, którym przyjrzymy się na reprezentatywnym przykładzie trzech szerokich typów systemów operacyjnych:

  • Tradycyjne, w pełni funkcjonalne systemy operacyjne
  • Minimalne systemy operacyjne ogólnego przeznaczenia
  • Systemy operacyjne zbudowane specjalnie dla kontenerów

W każdej kategorii wybrałem dwa przykłady, które będą reprezentować wszystkie dystrybucje i produkty w grupie.

Po przeczytaniu tego artykułu powinniście mieć znacznie wyraźniejszy obraz różnic między typami systemów operacyjnych. Zakładam, że poprawi się zrozumienie, dlaczego programiści mogą wybrać jeden kontenerowy system operacyjny zamiast innego dla aplikacji kontenerowych i dlaczego mogą wspierać te wybory lub kwestionować je.


W pełni funkcjonalne systemy operacyjne


Co oznacza „w pełni funkcjonalny system operacyjny”? I dlaczego w kontekście wdrożenia kontenera wszystkie funkcje miałyby znaczenie? W tej sekcji przyjrzymy się, dlaczego ten sam system operacyjny, który może być używany w tradycyjnym wdrożeniu serwera, może być najlepszą odpowiedzią na platformę kontenerową.

Przede wszystkim trzeba wiedzieć, że te systemy operacyjne potrafią to wszystko. Jeśli aplikacja potrzebuje funkcji, istnieje prawdopodobieństwo, że któryś z nich ją będzie miała. Elastyczność ma jednak swoją cenę: te systemy operacyjne wymagają od systemu najwięcej, jeśli chodzi o pamięć masową, pamięć RAM i zasoby procesora. Funkcje te zwiększają również powierzchnię ataku systemu operacyjnego, zapewniając potencjalnym napastnikom znacznie więcej zakamarków, w których mogą wykonywać swoją pracę. Są to koszty, które należy ponieść, jeśli te funkcje są potrzebne aplikacjom. Czasami cena staje się bardzo wysoka, jeśli wymagana jest tylko niewielka liczba funkcji.

Te w pełni funkcjonalne systemy operacyjne mogą być najbardziej odpowiednie w środowisku, w którym wiele różnych aplikacji jest wdrażanych w kontenerach na jednej instancji systemu operacyjnego. W takich przypadkach szeroki zakres funkcji może być najbardziej ekonomicznym sposobem obsługi floty aplikacji.


Ubuntu

Ubuntu stał się domyślnym systemem operacyjnym na serwerze, w chmurze, a nawet na komputerze stacjonarnym dla wielu organizacji. Dobrze wspierany przez firmę Canonical, Ubuntu jest dostępny w wielu różnych formatach do pobrania z pakietami narzędzi, powłokami, funkcjami i zestawami funkcji niezbędnymi do wdrożeń obsługujących IoT, kontenery, serwery lub chmury.

Ubuntu przeniosło się w przestrzeń zajmowaną niegdyś wyłącznie przez Red Hat Linux: jest to bezpieczny wybór dla wdrożeń w przedsiębiorstwach, z obsługą i reputacją, które sprawiają, że wybór jest uznawany przez większość komitetów wykonawczych za „rozsądny”. Należy jednak pamiętać, że rozsądek nie przekłada się na najlepszy w każdych okolicznościach - to wciąż duży, pełny system operacyjny z wieloma zbędnymi preinstalowalnymi pakietami.


CentOS

Tam, gdzie Ubuntu stał się najbardziej zaawansowanym wyborem dla przedsiębiorstw spośród w pełni funkcjonalnych systemów operacyjnych, CentOS jest otwartą, kierowaną przez społeczność wersją innego „bezpiecznego” wyboru - Red Hata. CentOS kładzie nacisk na wsparcie społeczności i wkład w rozszerzający się zestaw funkcji i funkcji w systemie operacyjnym, jednocześnie budując stabilność swojego fundamentu Red Hat. Nie oznacza to, że CentOS nie jest używany przez duże organizacje - znajdziesz go na serwerach w laboratoriach krajowych i u głównych dostawców chmury. Ale Ubuntu ma tendencję do oferowania szybszych aktualizacji niż CentOS, który zawiera pakiety, które wydają się być starsze, ale bardzo dobrze przetestowane.


Minimalne systemy operacyjne


Kontenery powstały jako zbiory minimalnych funkcji zebranych razem w kompletną aplikację. Jakich funkcji w „pełnych” dystrybucjach Linuksa brakuje w tych minimalnych systemach operacyjnych - i czy ma to znaczenie dla Twojej aplikacji? Z drugiej strony, jakie są zalety opierania aplikacji na pakietach zredukowanych do absolutnego minimum?

Najlepsze odpowiedzi znajdują się na przecięciu wymagań aplikacji i funkcjonalności systemu operacyjnego. Bez przemyślanego przygotowania można utracić korzyści związane z rozmiarem i złożonością, których oczekuje się od minimalnych systemów operacyjnych, poprzez dodanie indywidualnych narzędzi, funkcji i apletów wymaganych dla określonych aplikacji.

W tej sekcji omówiono dwie dystrybucje, BusyBox i Alpine Linux, oraz korzyści, jakie mogą one przynieść w odpowiednich okolicznościach. Te dwa systemy operacyjne są ze sobą powiązane - Alpine jest oparty na BusyBox - ale istnieją kluczowe różnice, które mogą skłonić zespół do wybrania jednego z nich dla poszczególnych wdrożeń. Różnice te dotyczą nie tylko określonych zdolności, ale także społeczności wsparcia i ekosystemu każdego z nich.


BusyBox

BusyBox jest stosowany powszechnie we wdrożeniach kontenerów, ponieważ nie został zaprojektowany z myślą o kontenerach. Nazwany przez twórców jako „szwajcarski scyzoryk wbudowanego systemu Linux”, BusyBox miał być pojedynczym plikiem wykonywalnym o niewielkich rozmiarach, który zawierał wszystkie funkcje wymagane przez większość wbudowanych aplikacji. To zmusiło go do przyjęcia podejścia zbliżonego do kontenera do wdrożenia, zanim kontenery powstały.

BusyBox można wdrożyć przy użyciu Linuksa lub innych systemów operacyjnych POSIX jako podstawy. Łączy się z wieloma popularnymi narzędziami Linuksa w uproszczonej formie. Rezultatem jest kompaktowy, jednoplikowy plik wykonywalny, który zawiera wiele funkcji „pełnej” dystrybucji Linuksa, chociaż wiele opcji funkcjonalnych dostępnych w tych pełnych wersjach zostało pominiętych w BusyBox w imię zaoszczędzonego miejsca.


Alpine Linux

Jak wspomniano, Alpine Linux jest oparty na BusyBox, ale opiera się na wcześniejszej dystrybucji zarówno pod względem celu, jak i szczegółów. Tam, gdzie BusyBox jest zaprojektowany z niewielkimi rozmiarami, jako jedyny cel, Alpine Linux używa wzmocnionego jądra, aby dodać bezpieczeństwo do kompaktowych, prostych celów swojego poprzednika.

Alpine Linux ułatwia również programistom dodawanie funkcji. Opierając swoją dystrybucję na BusyBox i bibliotece musl, Alpine Linux daje programistom przewagę nad dodawaniem funkcji i budowaniem kompaktowych pakietów dystrybucyjnych. Jest to minimalny system operacyjny zdolny do tworzenia bardzo małych obrazów kontenerów do wdrożenia, a wzmocnione jądro sprawia, że ​​nadaje się on do zastosowań produkcyjnych, a także programistycznych.


Kontenerowe systemy operacyjne

System operacyjny kontenera jest dostarczany po wyjęciu z pudełka z wbudowaną automatyzacją i orkiestracją kontenerów. Są one zaprojektowane i zbudowane jako systemy operacyjne „hosta” - system operacyjny, na którym są hostowane systemy operacyjne kontenerów, takie jak Alpine i BusyBox. Dlaczego więc nie są one automatycznym wyborem dla każdego wdrożenia kontenera?

Kontenerowe systemy operacyjne wyróżniają się tym, że nie są po prostu oprogramowaniem obsługującym kontenery, ale oprogramowaniem wdrażanym przy użyciu kontenerów. Architektura oparta na „kontenerach do samego końca” może zapewnić poziom dostosowania do wdrożenia, który jest znacznie bardziej złożony niż tradycyjne wdrożenie systemu operacyjnego. Z drugiej strony, dla organizacji na wczesnym etapie przechodzenia na kontenery lub we wdrożeniach aplikacji, które przekraczają granice architektur kontenerów, architektura „całkowicie kontenerowa” może być pomostem za daleko, jeśli chodzi o komfort zarządzania.

Rancher OS i Container Linux to dwie główne opcje dla osób poszukujących kontenerowych systemów operacyjnych. Zrozumienie, co każdy system wnosi pozytywnego, pomoże programistom zrozumieć zalety, które posiadają, oraz sytuacje, w których są jedynym logicznym wyborem.


RancherOS

Każdy proces w RancherOS jest uruchamiany w oddzielnym kontenerze zarządzanym przez Docker. Optymalizacja i zależność od Dockera pozwala RancherOS być bardzo małym z bardzo krótkim czasem rozruchu. Oprócz podstawowych korzyści związanych z wydajnością istnieją jednak czynniki związane z wdrażaniem, które mogą przemawiać na korzyść RancherOS.

Usługi systemowe RancherOS są definiowane i konfigurowane przez Docker Compose. Ta zależność oznacza, że ​​tylko usługi potrzebne dla aplikacji są ładowane i wdrażane, co dodatkowo przyspiesza i upraszcza wdrażanie. Wdrażanie jest ponownie uproszczone dzięki integracji z cloud-init, która umożliwia zautomatyzowaną konfigurację i wdrażanie na szeroką skalę i z dużą szybkością.


CoreOS Container Linux

CoreOS Container Linux jest przeznaczony do wdrażania kontenerów w skali chmurowej. Teraz, jako część Red Hat, Container Linux jest zoptymalizowany pod kątem wdrożeń klastrów w publicznych lub prywatnych infrastrukturach chmurowych.

Container Linux jest wdrażany z jądrem i niezbędnymi narzędziami w jednym pliku wykonywalnym, a wszystkie inne narzędzia i funkcje są wdrażane w kontenerach.

Container Linux jest od dawna w powszechnym użyciu, a wsparcie jest dostępne do wdrażania w większości chmur publicznych. Przejęcie go przez firmę Red Hat nie spowolniło jego wdrażania i sprawiło, że niektóre organizacje są bardziej zadowolone z pomysłu wdrożenia na platformie. Container Linux jest rozpowszechniany z licencją typu open source i ma aktywną społeczność programistów.


Podsumowanie

Biorąc pod uwagę trzy szerokie typy systemów operacyjnych dostępnych do wdrażania kontenerów, który system operacyjny kontenera powinien wybrać zespół programistów? Jeśli jedynym celem konkretnego serwera jest hosting kontenerów, to systemy operacyjne kontenerów, takie jak RancherOS i Container Linux, mają wiele do polecania. Ich automatyzacja, szybkość wdrażania i spójna architektura kontenerów sprawiają, że są one logicznym wyborem dla tych, którzy chcą zoptymalizować środowisko hostingu kontenerów. Po przejściu o jeden poziom w górę do systemów operacyjnych dla samych kontenerów, wybory stają się bardziej zniuansowane.


Kiedy bierzemy pod uwagę zarówno aplikacje kontenerowe, jak i inne niż kontenerowe, nie ma wątpliwości, że tradycyjne wdrożenia Linuksa, takie jak Ubuntu i CentOS, mogą być używane jako platforma kontenerowa. Ich architektura oraz lista narzędzi i funkcji spowodują, że będą wolniej uruchamiać się i będą wymagały więcej zasobów systemowych, ale mogą wykonać zadanie, jeśli szybkość rozruchu i minimalne zużycie zasobów nie są kluczowymi kwestiami.


Pośrodku znajdują się minimalne systemy operacyjne, takie jak BusyBox i Alpine Linux. Mogą to być same w sobie solidne opcje kontenerów, ale naprawdę mogą się przydać, jeśli istnieją ograniczone zasoby aplikacje niebędące kontenerami, takie jak te dla IoT, które również należy uznać za część całego środowiska aplikacji.


Zrozumienie różnicy między możliwościami i ograniczeniami różnych typów systemów operacyjnych ma kluczowe znaczenie dla każdej produktywnej dyskusji na temat platformy systemu operacyjnego. W przypadku nowoczesnych systemów operacyjnych prawdziwa rozmowa nie powinna wtedy dotyczyć tego, który system operacyjny będzie działał, ale który będzie wykonywał pracę najbardziej wydajnie i efektywnie.

9 maja 2020

Clonezilla - narzędzie OpenSource do kopiowania, klonowania dysków i partycji + backupów



W okolicy w roku 2000 kiedy poznawałem na co dzień system FreeDOS, FreeBSD oraz zalążek systemu Linux - a precyzyjniej MINIXa - używałem jeszcze wtedy Windows.

Bardzo wygodnym narzędziem do zamrażania stanu systemu był wtedy Norton Ghost.

Jego głównym zadaniem był backup (kopia) całego obrazu dysku lub partycji systemowej do pliku. Mając taki plik, można było odtworzyć system do stanu z momentu backupu. To nowatorskie narzędzie - jak na tamte czasy działające z własnym GUI w konsoli systemu DOS - pozwoliło po zainstalowaniu systemu obraz w sterowników do niego, zrobić kopię całego obrazu, która mogła być wykorzystywana wielokrotnie. Było to wtedy związane z tym, że rejestr systemu Windows łatwo się zaśmiecał wraz z instalacją oprogramowania.




Po około 20 latach okazało się, że zechciałem zrobić klon dysku inną metodą niż przy pomocy programu disk dump w skrócie dd.

Po drodze sprawdziłem GParted oraz gnome-disks, jednak te narzędzia służą do zarządzania dyskami i partycjami, nie specjalizują się w klonowaniu dysków, czy też partycji.




Jak wiadomo podszedłem do tego od razu tak, że poszukałem oprogramowania otwartego i moim oczom ukazał się obraz systemu operacyjnego Linux pod nazwą Clonezilla - dedykowana dystrybucja Linuxa do klonowania, kopiowania, backupowania dysków i partycji.

Zanim jednak użyłem dedykowanego narzędzie Clonezilla, postanowiłam próbować wykorzystać program disk dump w skrócie dd i zrzucić obraz systemu na którym pracuje.

Wiedziałem że będzie w domu skazane na niepowodzenie ale nie widziałem żadnego komunikatu z kernela Linuksa który zabezpiecza system w takich sytuacjach.

Najprostsze użycie:

dd if=/dev/sda of=/dev/sda bs=16MB



Oczywiście, jak się spodziewacie efektem ubocznym nie był sławetny blue screen, lecz alarm z jądra systemu Linux dotyczący naruszenia obszarów, które mapują fizyczny dysk na logiczny File system. Poniżej zrzut ekranu wraz z komunikatem:




Na tyle mi wystarczyło rozgrzewki potwierdzającej, że w systemie Linux są zabezpieczenia, które nie pozwalają w trakcie działania żywego systemu robić klon dysku. Na pewno nie taką prymitywną metodą z użyciem polecenia dd.

Każdy eksperyment daje nam pewność w hipotezie, którą sobie stawiamy. Ja zakładałem, że tak właśnie się to powinno zakończyć i wróciłem do softu Clonezilla.



Jak przebiega proces klonowania dysku z użyciem Clonezilla?

Na początku warto zorientować się, jakie oznaczenia w /dev mają dyski, które podłączyliśmy fizycznie do komputera. Ja wykorzystywałem adapter serwisowy dla dysku docelowego, źródłowy był w komputerze zamontowany.

Polecenia Linuxa, które odsłania nam listę urządzeń dyskowych to:


df -h - pokazuje dyski, partycje wraz z zajętością oraz podmontowane

lsblk - pokazuje urządzenia przenośne, pendrive lub karty SD

lsusb - pokazuje, czy nasz kabelek lub narzędzie do podłączenia dysku na USB jest widoczne.


Oczywiście warto wspomnieć o poleceniu dmesg, dzięki któremu w logu systemowym zobaczymy fakt fizycznego podłączenia dysku oraz nadaną ścieżkę dla dysku np: /dev/sdb.


Na wstępie pobieramy obraz systemu ISO dla Clonezilla z oficjalnej strony.

Po czym używając np: dd lub gnome-disks zapisujemy na pendrive lub innym dysku obraz z systemem backupującym Clonezila, z którego następnie uruchamiamy komputer. Naszym oczom pojawia się taki komunikat i po wybraniu w konfiguracji właściwych opcji (źródłowy dysk, docelowy dysk, czy kopiujemy MBR) wygląd klonowania przedstawiają poniższe zdjęcia:













Dla dysku źródłowego SSD na docelowy 320GB 5400 WD BLUE, proces trwał ok. 45 minut, na laptopie DELL z 4 core CPU i 16GB RAM.


Po wykonaniu klona, restartu i uruchomeniu z laptopa ze sklonowanego dysku, po ok. 10 minutach cały system wystartował pomyślnie i można go używać bez żadnych problemów.

Polecam narzędzie Clonezilla jako świetne i wygodne narzędzie warsztatowe do backupów dysków. Oczywiście, o czym nie wspomniałem, tak jak Norton Ghost to narzędzie potrafi zapisać obraz dysku do pliku, a nawet wykonywać przyrostowe backupy.

Warto nadmienić, że Clonezilla można zainstalować niezależnie oraz uruchomić z dysku jako Clonzilla Live, w powyżej opisanym przypadku używałem wersji Live z odrębnego dysku.

Jest jeszcze jedna ważna kwestia - Clonzilla potrafi zaszyfrować plik backupem :-) Powodzenia podczas buckupowania lub / i klonowania dysków / partycji.

19 marca 2020

Identicon, avatar, robohash i inne graficzne reprezentacje danych

Widzieliście nieraz ikonki generowane z automatu i być może zastanawia Was, czym są, jak powstają, czy ich ilość jest skończona. W tym wpisie postaram się nakreślić ogólnie zarys koncepcji kilku powszechnych:

Naturalnie w/w identyfikatory można wygenerować sobie przy pomocy kodu OpenSource (linki pod w/w nazwami). To nie jest koniec, jeśli chodzi o eksplorację indenticon, oto lista na githubie do wyników wyszukiwania implementacji identicons w różnych językach programowania.

Rozpocznę kilkoma wygenerowanymi przykładami, które przybliżą, o czym chciałbym tutaj napisać:







Jak niektórzy zdążyli zauważyć najbliższy branży IT identicon to wizualizacja odcisku klucza OpenSSH. Kiedy generujemy klucz, jak pamiętacie pojawia się taka jak w animacji powyżej tekstowa reprezentacja.
Wszelkie identicony mają na celu pokazać w postaci obrazka odcisk/odpowiednik klucza lub napisu, który wprowadza się na wejście.

Jak pewnie niektórzy kojarzą, domyślny avatar w githubie jest właśnie generowany takim sposobem. Projekt WordPress również ma swoje odpowiedniki.
Często mamy sytuację, w której chcemy w łatwy sposób rozróżnić osoby, których tylko imię lub pseudonim znamy - tutaj przydają się identikony. Prawdopodobnie najczęstszymi ich przykładami są różne osoby na różnych platformach dyskusyjnych, takich jak czaty, fora, strony wiki lub systemy śledzenia incydentów/problemów.

Punktem wyjścia do wizualizacji dowolnych danych jest często funkcja skrótu lub z ang. hashowanie. Hashowanie w tym kontekście ma na celu przedstawienie wartości stałej długości na podstawie zmiennej długości danych wejściowych. Ta reprezentacja stałej długości jest tylko dużą liczbą, która może być następnie wykorzystana jako punkt wyjścia do rozróżnienia różnych informacji.

W momencie, kiedy mamy już liczbę możemy w powtarzalny sposób stworzyć reprezentację na jej podstawie. I tak dzięki trickom programistycznym, artystycznej fantazji i oszukiwaniu wzroku można ukrywać ale też przekazywać informację wizualną ludziom. Jest taki dość znaczący rozdział psychologii oraz dziedzin pochodnych t.j. doświadczenie użytkownika (ang. User Experience / UX), gdzie tzw. Pre-attentive Processing jest wykorzystywany. Zakładamy, że człowiek posiada ograniczoną percepcję wzrokową i aparat wzroku działa w sposób specyficzny. To oznacza, że niektórymi cechami obrazu można na odbiór informacji wpływać świadomie lub podświadomie.
Czyli np. bazując na mieszaniu koloru, nasycenia barwy, jasności, formy, położenie przestrzenne i przesunięcia można zbudować dość atrakcyjne wizualizację i ikony. Jest też ogromna dziedzina (ikono)grafiki komputerowej, która bazuje zasadniczo m. in. na tych założeniach.

Z punktu widzenia realizacji i algorytmów używanych w identicons, są to sprytne kilku linijkowe przesunięcia bitów/maskowania/mieszania z losowaniem wartości. Istnieją też opcje losowania elementów identicon z listy kilku obrazków bazowych i składanie w całość t.j. tutaj w MonsterID:



Kolejnym wartościowym przykładem użycia identiconów są portfele wirtualnej waluty (kryptowalutyEthereum:



Moim faworytem ze względu na zainteresowanie robotyką oraz atrakcyjny wygląd są RoboHASHe. 
Istnieje wiele gotowych generatorów t.j. np: ten dla RoboHash.



Obliczmy liczbę różnych robotów, które możemy wygenerować:
- Istnieje 5 różnych części ciała
- Istnieje 10 różnych kształtów dla każdej części ciała
- Istnieje 10 różnych kolorów robota
- Istnieje 10 różnych kolorów tła
W sumie to 10⁵ * 10 * 10 = 10 000 000 różnych robotów. 
Nie jest to nawet blisko liczby różnych adresów, która wynosi ~ 2²⁵⁶ = 10⁷⁷. 
Chociaż prawdopodobnie niemożliwe jest wygenerowanie czegoś zbliżonego do 10⁷⁷ różnych, 
dobrze rozpoznawalnych, dobrze zapamiętywalnych identiconów na powierzchni 128x128 pikseli, 
tylko dlatego, że zdolność ludzi do przetwarzania obrazów jest ograniczona. 
Dlatego identicons nigdy nie może być pomiarem bezpieczeństwa 
i nigdy nie zastąpi potrzeby dokładnego sprawdzenia adresu przed potwierdzeniem krytycznego transferu. 
Chociaż ich entropia jest pomijalna w porównaniu do przestrzeni adresowej, 
aby szybko uzyskać przegląd historii transakcji lub rozróżnić własne konta, identicons są bardzo cenne.

Warto zdawać sobie sprawę, że w branży IT potrzeba jest matką wynalazców i tak też w przypadku identiconów było - po prostu ludzie nie wgrywali swoich avatarów/ikonek, przez co pustka została zapewniona twórczością artystów-programistów :-)

Jeśli posiadacie swoje patenty/algorytmy na identicony, zapraszam do umieszczania w komentarzach linków do kodu lub gotowych generatorów.



Materiały: