Docker to obecnie niezbędne narzędzie dla większości programistów. Według badań Stack Overflow, Docker jest technologią, której znajomość jest najbardziej pożądana przez programistów.
Znajomość Dockera przydaje się w wielu rozwiązaniach chmurowych m.in.
Kubernetes,
Azure App Services,
Amazon Elastic Container Service.
Docker – czym jest i w jaki sposób mogą go wykorzystać programiści?
Aby móc wykorzystać potencjał narzędzia, warto je dobrze poznać. Odpowiedzmy sobie najpierw na pytanie czym właściwie jest Docker, kontener i obrazy, używane przez kontenery.
Docker jest obecnie jednym z kilku narzędzi, które uruchamiają kontenery. Inne narzędzia o tej samej funkcji to np. Containerd lub CRI-O. Dzięki kontenerom możemy aktywować dodatkowy, odizolowany system operacyjny z gotową do działania aplikacją. Kontener nie emuluje całej warstwy sprzętowej – dzięki niemu otrzymujemy pełnoprawny system operacyjny wraz ze zdefiniowanym procesem aplikacji. Nie zużywa też takiej ilości zasobów, co wirtualizacja.
Kontenery Dockera działają niezależnie od siebie i do chwili, w której świadomie wskażemy zależność pomiędzy nimi, nic o sobie nie wiedzą. Jeśli, przykładowo, chcemy uruchomić bazę danych dla naszej aplikacji, to istnieje taka możliwość. Polega ona na uruchomieniu kolejnego kontenera z bazą i stworzeniu połączenia sieciowego pomiędzy kontenerami.
W dokumentacji Dockera często wymieniane jest określenie „container image”. Podkreśla ono zależność – kontener powstaje na podstawie obrazu.
Obraz kontenera to lekki, samodzielny, wykonywalny pakiet oprogramowania, który zawiera wszystko, co jest potrzebne do uruchomienia aplikacji:
kod,
środowisko wykonawcze,
narzędzia systemowe,
biblioteki systemowe,
ustawienia.
Uruchamianie i budowanie kontenerów
Poniżej przedstawię kilka przykładowych poleceń, które uruchamiają i budują kontenery. W kolejnych artykułach je rozwinę.
Uruchamianie kontenera:
Uruchomienie ubuntu z powłoką bash
docker run -it ubuntu:22.04 bash
Uruchomienie centos z powłoką bash
docker run -it centos:centos8.4.2105 bash
Uruchomienie kontenera polega na wskazaniu obrazu, na podstawie którego ma działać, i podaniu opcjonalnej konfiguracji. Powyższe polecenia uruchamiają systemy operacyjne w wybranej wersji. Wywołanie powłoki bash uruchamia proces o tej nazwie w kontenerze i umożliwia wykonywanie w nim poleceń.
Budowanie obrazu kontenera
Zawartość pliku Dockerfile
FROM tomcat:8.0 ADD /usr/local/tomcat/webapps/
Budowanie obrazu
docker build -t sample-app-tomcat-1.0.0 .
Uruchomienie lokalnego obrazu z udostępnieniem portu 8080
docker run -p 8080:8080 sample-app-tomcat-1.0.0:latest
Budowanie obrazu to zapisanie stanu kontenera w formie pliku. W podanym przykładzie, na podstawie bazowego obrazu Tomcat, powstaje obraz z przykładową aplikacją W ten sposób otrzymujemy obraz gotowy do uruchomienia z powtarzalną konfiguracją, wskazanymi wersjami oprogramowania – gotowy do działania.
Współdzielenie obrazu kontenera
Aby współdzielić obraz i móc uruchomić go na kolejnych środowiskach, mamy dwie możliwości:
zapisanie obrazu w postaci pliku tarball,
zapisanie obrazu w publicznym lub prywatnym rejestrze obrazów.
Pierwszy sposób wykorzystuje się, kiedy docelowe środowiska nie mają dostępu do internetu. Natomiast najpowszechniejszym sposobem jest wykorzystanie rejestru.
Do publicznego rejestru każdy może dodawać obrazy – co jest jednocześnie jego zaletą i wadą. Dostępne, oficjalne obrazy budowane przez opiekunów oraz twórców konkretnych rozwiązań, są bezpieczniejsze od obrazów utworzonych przez prywatne osoby.
Jakie są korzyści wykorzystania Dockera dla programistów?
Konteneryzacja dla programisty oznacza sposób, w jaki może dostarczyć aplikację ze wszystkimi potrzebnymi zależnościami i wybranym systemem operacyjnym. Co ważne, może zrobić to w określonych przez niego wersjach, dzięki czemu uruchomienie aplikacji na kolejnych środowiskach (włączając produkcyjne) jest bardziej przewidywalne.
Przykładowo: jeśli uruchamiamy aplikację Java na Apache Tomcat, to obraz kontenera zawiera zainstalowany system operacyjny (np. Ubuntu lub CentOS), zainstalowaną maszynę Java oraz Apache Tomcat i paczkę WAR z aplikacją. Jedynym uruchomionym procesem staje się wówczas wirtualna maszyna Javy z Tomcatem i naszą aplikacją.
Docker pozwala wykorzystywać gotowe obrazy zainstalowanych systemów, aplikacji i baz danych, które zostały wcześniej przygotowane i umieszczone w publicznym rejestrze. Dzięki temu, jeśli chcemy używać PostgreSQL, Redis, RubyOnRails albo Wildfly, jest duża szansa na to, że gotowy obraz będziemy mogli pobrać z repozytorium i nie stracimy czasu na jego przygotowanie.
Jeśli jednak nie znajdziemy tego, czego szukamy, to zawsze możemy zbudować własny obraz, bazując na jednym z bardziej generycznych, zawierających tylko zainstalowany system operacyjny (Ubuntu, Fedora, Alpine itp…) lub zainstalowane środowisko uruchomieniowe (Java, Python czy ASP.NET).
Wykorzystując kontenery zyskujemy:
Łatwość tworzenia oraz powtarzalność środowisk deweloperskich.
Uproszczenie procesów dostarczania gotowych aplikacji na docelowe środowiska w szczególności rozproszone.
Uruchamianie na Windows, Linux, macOS, Kubernetes.
Możliwość eksperymentowania z różnymi wersjami oprogramowania.
Kilka słów podsumowania
Widać wyraźnie, że środowisko deweloperskie można zbudować z gotowych obrazów zawierających zainstalowane kontenery i usługi. Mechanizm budowania obrazów kontenerów możemy wykorzystać także w drugą stronę i dostarczać nasze konkretne aplikacje w postaci obrazów. Bez względu na technologię wykorzystaną w aplikacji, obraz kontenera będzie dostarczany w identyczny sposób, co upraszcza procedury instalacyjne.
Proces dostarczania aplikacji może zostać zautomatyzowany przez odpowiednie narzędzia.
Kontenery były od samego początku wspierane przez systemy Linux, jednak obecnie są dostępne również na Windows.
Windows Subsystem dla Linux (WSL 2) wprowadził istotną zmianę – pozwala uruchamiać kontenery Linuxa natywnie, bez wirtualizacji.
W przypadku macOS niestety potrzebna jest dodatkowa wirtualizacja.
W następnych wpisach postaram się opisać tworzenie obrazów Dockera oraz budowanie środowiska deweloperskiego.
Dla urządzeń pracujących w ramach platformy IQRF, na których można uruchomić programy pisane w języku Java, dostępne są bezpłatne narzędzia programistyczne tworzące środowisko projektowe IQRF SDK obejmujące m.in. biblioteki i zestaw API, a także obszerną dokumentację i przykładowe kody aplikacji.
IQRF SDK, służy do pisania programów w języku Java i wykorzystuje zintegrowane środowisko NetBeans. Opracowywanie projektów ułatwiają biblioteki obsługujące interfejsy SPI i UART oraz CDC (Connected Device Configuration) i protokół UDP, a także frameworki Simply i Simply IQRF DPA. Simply pozwala budować aplikacje komunikujące się z sieciami czujnikowymi, dając strukturę współpracującą z różnymi technologiami, a Simply IQRF DPA rozszerza framework o implementację technologii DPA.
Opisywane narzędzia obsługują wszystkie standardowe peryferia DCTR, pozwalając też na realizację obsługi peryferiów użytkownika i są przy tym wygodne w użyciu. Peryferia DCTR w sieci są dostępne za pośrednictwem metod, które można wywoływać synchronicznie lub asynchronicznie. Interfejs komunikacyjny wybierany jest za pomocą jednego pliku konfiguracyjnego, a ważne zdarzenia w systemie podlegają logowaniu.
Oprogramowanie jest otwarte: kody źródłowe można znaleźć na profilu firmy Microrisc w portalu GitHub, a pakiety Javy na stronie. Możliwość współpracy i wymiany wiedzy zapewnia natomiast narzędzie Confluence.
W następnej edycji SDK dostępna ma być także możliwość pracy z urządzeniami nie obsługującymi Javy, programowanymi w języku C oraz zestaw sterowników dla układów wbudowanych nie pracujących pod kontrolą systemów Windows czy Linux.
Zapowiadany jest także sterownik SPI dla modułów Gemalto, biblioteka obsługująca DPA dla mikrokontrolerów bez systemu operacyjnego, obsługa dynamicznych zmian struktury sieci oraz obsługa integracji z chmurą IQRF Cloud.
Szczegółowe informacje, dokumentacja oraz możliwość pobrania narzędzi są dostępne na stronie IQRF.
Dystrybutorem produktów IQRF w Polsce jest firma Soyter Sp. z Klaudyn, ul. Ekologiczna 14/16, 05-080 Izabelin, http://www.soyter.pl.
W poprzedniej części skupiłem się na Xcode oraz elementach wchodzących w jego skład. Tym razem opiszę narzędzia innych firm oraz te stworzone przez społeczność.
Tak samo jak poprzednio – zaznaczam, że nie są to wszystkie dostępne narzędzia i wcale nie muszą być najlepsze. Z mojego doświadczenia wynika, że są najpowszechniej używane, najbardziej lubiane lub po prostu najbardziej istotne.
Homebrew
To narzędzie musi znać każdy programista pracujący na macOS. Jest to najpopularniejszy makowy menedżer pakietów. Instalujemy nim większość konsolowych narzędzi – od nowszej wersji gita do Node.js. Instrukcja instalacji (po polsku!) jest dostępna na stronie brew.sh.
Warto przy okazji wspomnieć parę ważnych narzędzi instalowanych przez Homebrew. Poza wspomnianym gitem dobrze jest od razu zainstalować m.in. SwiftLint, Chisel oraz rbenv. To pierwsze służy do utrzymania odpowiedniego stylu Swiftowego kodu, a drugie to zestaw narzędzi wspomagających debugowanie przy użyciu LLDB, o którym wspominałem już poprzednim razem.
Rbenv to inny menedżer, ale w tym przypadku interpreterów Ruby. Bardzo przydaje się do tego, by (poza korzystaniem z nowszej wersji ruby) móc instalować gemy lokalnie, a nie w ścieżkach systemowych z użyciem sudo. W postaci gemów otrzymamy narzędzia “must-have”, takie jak Fastlane oraz CocoaPods (opisane poniżej).
Fastlane
Jest to zbiór narzędzi automatyzujących pracę z projektami iOS (również Android, ale tam nie aż tak powszechnie). Opisanie w szczegółach Fastlane zapewniłoby mi tematy do pisania na najbliższe dwa lata. Biorąc pod uwagę tempo rozwoju to w sumie mógłbym nigdy nie zdążyć tego zrobić… Każdy, kto na poważnie interesuje się programowaniem na iOS musi to znać. Najciekawsze moim zdaniem elementy będące częścią Fastlane to match oraz snapshot.
Match usprawnia podpisywanie kodu. Automatyzuje m.in. pobieranie kluczy, certyfikatów i profili od Apple. Pozwala nawet na synchronizowanie ich między komputerami poprzez specjalne repozytorium git!
Snapshot automatyzuje tworzenie zrzutów ekranu aplikacji poprzez wykonanie napisanego wcześniej testu UI i zrobienie zrzutu w odpowiednim momencie. I tak dla każdego rozmiaru urządzenia i każdego języka aplikacji. Ta ilość idzie w setki, a ręczne wykonywanie takiej pracy zakrawa o masochizm. Oczywiście jest też odpowiedni moduł fastlane zajmujący się wysyłaniem tych plików do iTunes Connect. Snapshot przyda się również, gdy chcemy skasować dane z wszystkich symulatorów.
Twórcy pracują także nad serwerem CI, który nazywa się (niespodzianka!) oraz bazuje na bardzo nowoczesnych (i aktualnie modnych) rozwiązaniach takich jak np. przetrzymywanie konfiguracji CI w repozytorium git.
xcode-install
Standardowo Xcode instaluje się poprzez Mac App Store. Ma to jednak swoje minusy – przede wszystkim można mieć tylko jedną wersję naraz. No i może się ona przypadkiem zaktualizować (lub nie). Do tego instalując inne wersje Xcode (szczególnie na CI) trzeba pamiętać aby dać im dostęp do kluczy prywatnych służących do podpisywania aplikacji itp.
Tutaj wyręczy nas xcode-install. Trzeba jednak mieć na uwadze pewne błędy przy instalacji Xcode w wersji beta – narzędzie nie rozróżnia ich i najpierw trzeba starą betę odinstalować, by bez problemu zainstalować nową.
CocoaPods, Carthage, SPM
Opisują te rzeczy w jednym rozdziale, ponieważ wszystkie mają ten sam cel – zapanowanie nad zależnościami. Co ciekawe bardzo się od siebie różnią.
CocoaPods jest najstarsze i ma największe możliwości, ale też najbardziej ingeruje w pliki projektu.
Carthage jest nowsze i jak można przeczytać w nagłówku “nie modyfikuje plików projektu ani ustawień budowania“. Osobiście nie mam nic przeciwko żadnemu z nich ale uważam, że poprawne i bezpieczne używanie CocoaPods jest co najmniej trudne.
Swift Package Manager (SPM) jest bardzo świeży i rozwijany przez Apple, ale póki co używa się go raczej w przypadku projektów innych niż aplikacje iOS czy macOS. Najczęściej można się z nim spotkać przy pisaniu aplikacji serwerowych w Swift.
iTerm 2
Wszystkich wymienionych wyżej narzędzi używa się z linii poleceń. Istnieją co prawda takie aplikacje jak Cakebrew lub CocoaPods App, ale jest to raczej awangarda. Warto się więc wyposażyć w dobry terminal.
Aktualnie wróciłem do systemowego, który jest bardzo dobry, ale bardzo długo korzystałem z iTerm 2. Lista funkcjonalności jest bardzo długa i osoby uwielbiające Vima z pewnością będą chciały coś bardziej rozbudowanego niż systemowa aplikacja.
Niezależnie od preferencji dotyczących aplikacji do terminala polecam zainstalować Oh My Zsh lub ewentualnie fish. Nie wyobrażam sobie już używania standardowej konsoli.
Dash
Dash to po prostu przeglądarka dokumentacji. Ale nie tylko iOS – na stronie producent chwali się liczbą zestawów dokumentacji przekraczającą 200. Jest to też jedyna płatna aplikacja na tej liście, ale uważam, że jest warta każdego centa.
Integracja z wieloma środowiskami, zasób dokumentacji oraz wygoda (np. tryb HUD zmapowany pod skrót klawiszowy) to funkcje, które bardzo usprawniają pisanie kodu.
Ciekawostką może być też, że autor doczekał się własnej afery kiedy to jego konto deweloperskie zostało zawieszone, a aplikacje usunięte ze sklepu.
SourceTree
Są różne GUI do gita na macOS i jest SourceTree.
Wygląda ładnie, jest aktywnie rozwijane przez znaną firmę (Atlassian, twórców Jira) i posiada zaimplementowane praktycznie wszystkie funkcje gita potrzebne na co dzień. Można nawet robić interactive rebase!
Fakt, mogłoby działać trochę szybciej ale i tak pracuje się z nim szybciej niż z linią komend – no chyba, że jesteśmy prawdziwymi miłośnikami konsolowego gita.
Edytor tekstu i kodu
Tego jest bardzo dużo, ale wspomnę z obowiązku chociaż o czterech, które wydają mi się najpopularniejsze. Zdaję też sobie sprawę z tego, że granica pomiędzy edytorem tekstu, a IDE jest aktualnie bardzo niewyraźna.
Atoma oraz Visual Studio Code pewnie wszyscy już znają, więc nie będę się rozpisywał. Osobiście na co dzień używam VS Code, bo działa trochę szybciej i ma wystarczająco dużo funkcjonalności. Oba niestety są zrobione na Electronie i nie polecam ich stosowania przez dłuższy czas z dala od zasilania.
Sublime Text 3 jest uwielbiane przez wiele osób przede wszystkim za szybkość działania. Teoretycznie trzeba je kupić jeśli zamierzamy z niego korzystać, ale wersja testowa nie posiada żadnych ograniczeń.
TextMate jest najbardziej “makowym” edytorem i też jedynym z zestawienia posiadającym wersję jedynie na macOS. Nie posiada bardzo rozbudowanych możliwości ale działa szybko, przyjemnie i będzie odpowiednim wyborem dla osoby, która lubi natywne aplikacje macOS.
Inne
Mógłbym wspomnieć również o aplikacjach typu Paw, Sketch albo Sip czy też przeróżnych komunikatorach (i tak w nieskończoność) ale kiedyś trzeba skończyć, więc zostawiłem tylko te moim zdaniem najważniejsze.
Dajcie znać, jeśli zapomniałem o czymś ważnym, a dodam to do tej listy.
Do następnego!
Leave a Comment