Uczestnik przychodzi na kurs lub kurs intensywny. Widzi uporządkowane rzędy wsparcia technicznego, starannie poprowadzone kable zasilające, układ sali wykładowej w szachownicę, jasne obrazy i schematy slajdów. Mówcy, którzy żartują i uśmiechają się, przekazują informacje w taki sposób, że masz czas na ich zrozumienie. Stojaki rozstawione, zadania ćwiczeniowe po prostu lecą z palców, z tą różnicą, że czasami potrzebna jest pomoc personelu technicznego. wsparcie.
A także przerwy kawowe w gronie podobnie myślących ludzi, wesoła i energetyczna atmosfera, wymiana doświadczeń, najbardziej nieoczekiwane pytania do prelegentów. Zarówno odpowiedzi, jak i informacje, których nie znajdziesz w podręcznikach, a jedynie w praktyce.
Jak myślisz, ile czasu, wysiłku i nerwów wymagało, aby wyglądało to dokładnie tak?
Dziękuję Wołodii Guryanovowi, certyfikowanemu administratorowi Kubernetesa oraz inżynierowi/liderowi zespołu w Southbridge, który od samego początku był świadkiem i aktywnie uczestniczył w tworzeniu wielu kursów Slurm.
Dostrzegł kulisy tworzenia kursów – złożoność i cierniste grabie, spostrzeżenia i nieoczekiwane rozwiązania. Oraz znane już intensywne rozwiązania Kubernetes, takie jak Slurm Basic i Slurm Mega. I nowy, w dużej mierze zmieniony kurs , który nieubłaganie się zbliża i rozpocznie się 19 sierpnia.
Ale może dość tekstów, przejdźmy do samej historii. Jak z kilku intensywnych tematów stworzyć całkowicie samowystarczalny i wieloaspektowy . Zacznę więc od historii o tworzeniu i rozwijaniu kursów – tak jak „Dawno, dawno temu w odległej galaktyce…”
Co kryje się za kulisami?
Jeśli zapytacie jak tworzymy kursy i od czego to wszystko się zaczyna, odpowiem po prostu: „Wszystko zaczyna się od pomysłu”.
Zwykle pomysł bierze się skądś – nie siedzimy skuci w piwnicy, dopóki nie wpadniemy na pytanie: „Na jaki temat zrobić kurs?” Pomysły przychodzą skądś same, ze źródeł zewnętrznych. Czasami ludzie zaczynają aktywnie pytać: „Co wiesz o takiej a takiej konkretnej technologii?” Albo jak to było z Dockerem, że nie dało się go zmieścić w czasie kursu intensywnego – widocznie trzeba było go zabrać na zewnątrz, żeby mieć czas, żeby coś opowiedzieć w trakcie kursu intensywnego.
Tak pojawia się pomysł.
Po jego ogłoszeniu, moim zdaniem, zaczyna się najtrudniejszy moment – ogólne zrozumienie, co uwzględnić w tym kursie – jest to bardzo porównywalne z przygotowaniem prelegentów na jakąkolwiek konferencję.
Jest jeden główny ból, gdy wydaje się, że wybrałeś temat i myślisz: „Co mogę o tym powiedzieć? To jest zbyt proste, to jest oczywiste, wszyscy też o tym wiedzą.”
Ale w rzeczywistości wcale tak nie jest. I osobiście w wielu miejscach powtarzam, że to, co wydaje się wam oczywiste, tym, którzy przychodzą was słuchać lub brać udział w kursach, wcale nie jest oczywiste. I tu pojawia się tak duża warstwa pracy i wewnętrznego konfliktu, co uwzględnić w kursie. W rezultacie otrzymujemy taką listę rozdziałów z tak zamaszystymi, dużymi pociągnięciami, o czym będzie kurs.
A potem zaczyna się prosta, rutynowa praca:
- Wybór materiału
- Przeczytaj uważnie dokumentację aktualnej wersji, ponieważ świat IT rozwija się obecnie w kosmicznym tempie. Nawet jeśli nad czymś pracujesz i robisz o tym kurs, to musisz zajrzeć do dokumentacji i zobaczyć, co tam nowego, o czym warto porozmawiać, o czym szczególnie warto wspomnieć.
- I pojawia się pewien szkielet kursu, gdzie w sumie większość tematów jest już przerobiona i wydaje się, że cokolwiek tam jest - nagraj filmy i wypuść je do produkcji.
- Ale tak naprawdę nie, wtedy zaczyna się ciężka praca, ale nie dla autorów kursu, ale dla tych, którzy testują. Zwykle nasi alfa testerzy to wsparcie techniczne, które w pierwszej kolejności sprawdza kursy pod kątem ewentualnych błędów składniowych i gramatycznych. Po drugie, biją nas boleśnie kijami i przeklinają, gdy pojawiają się miejsca zupełnie nieoczywiste, niezrozumiałe. Kiedy w tekstach pojawiają się złożone, kilkustronicowe zdania podrzędne lub oczywiste bzdury. Oni to wszystko przeczytali, uważajcie na to.
- Następnie rozpoczyna się etap testowania praktycznego, podczas którego wyłapywane są także pewne oczywiste niedziałające rzeczy i pokazywane są pewne punkty, które można albo utrudnić, ponieważ staje się to mało interesujące – po prostu siedzenie i kopiowanie – oraz identyfikowane są miejsca, w których jest bardzo trudne i mamy wiele do zrobienia od osób, które wezmą udział w tym kursie. A potem pojawiają się rekomendacje: „Chłopaki, uprośćcie to tutaj, łatwiej będzie to dostrzec i będzie z tego więcej korzyści”.
- Po wykonaniu tej ilości pracy, napisaniu części dotyczącej filmu, wszystko wydaje się być w porządku. I już można go przekazać na produkcję, na reklamę tego kursu. Ale znowu nie, jest za wcześnie - ponieważ ostatnio przestaliśmy trochę ufać sobie i w zasadzie zaczęliśmy więcej pracować z informacją zwrotną. Jest coś takiego jak beta testy - wtedy zapraszane są osoby z zewnątrz, niezwiązane w żaden sposób z naszą firmą i za jakieś gadżety pokazywane są im wszystkie części kursu, filmy, teksty, zadania praktyczne, tak aby mogły ocenić jakość materiału, jego dostępność i pomógł nam uczynić kurs tak dobrym, jak to tylko możliwe.
- A kiedy przejdzie kilka takich iteracji, głośniki, testy alfa w formie wsparcia technicznego, testy beta, ulepszenia. A potem wszystko zaczyna się od nowa – wsparcie techniczne, testy beta, ulepszenia.
- I w pewnym momencie przychodzi zrozumienie, że albo mamy dość modyfikacji, bo upewnienie się, że wszystkim się podoba, jest zupełnie nierealne, albo zostaną podjęte jakieś drastyczne decyzje. Kiedy wiele komentarzy w określonych miejscach jest krytycznych, przepisz je globalnie, bo coś poszło nie tak.
- Potem przychodzi czas na drobne poprawki – gdzieś zdanie nie jest zbyt ładnie sformułowane, gdzieś komuś nie podoba się czcionka 14,5, a wolałaby 15,7.
- Kiedy tego typu komentarz pozostanie, to wszystko, kurs mniej więcej się otwiera, rozpoczyna się oficjalna sprzedaż.
I na pierwszy rzut oka krótkie i proste zadanie stworzenia kursu okazuje się wcale nie takie proste i zajmuje niesamowicie dużo czasu.
Jest jeszcze jedna ważna kwestia: praca z kursem nie kończy się w momencie jego wydania. Po pierwsze, uważnie czytamy komentarze pozostawione w niektórych częściach. I mimo wszelkich wysiłków, jakie włożyliśmy, pewne niedociągnięcia wciąż są identyfikowane, niektóre błędy są po drodze poprawiane i ulepszane, w czasie rzeczywistym, tak aby każdy kolejny użytkownik otrzymał lepszą obsługę.
Każdy kurs ma swojego Product Ownera, który oprócz zdefiniowania ogólnej koncepcji sprawdza terminy, robi notatki na marginesach, że gdy przyjdzie czas na całkowite przepisanie kursu, a na pewno nadejdzie, bo za dwa lata, lub nawet rok później część tego, co mówimy, stanie się nieistotna po prostu dlatego, że stanie się moralnie przestarzała. Właściciel produktu zapisuje na marginesach, że najczęściej ludzie pytają, które punkty były niejasne, jakie zadania wydawały się bardzo trudne, a które wręcz przeciwnie, wydawały się bardzo proste. A wszystko to jest brane pod uwagę przy ponownym nagrywaniu kursu, podczas pewnego rodzaju refaktoryzacji, dzięki czemu każda iteracja globalnego kursu staje się lepsza, wygodniejsza i wygodniejsza.
Tak wyglądają kursy.
Jak narodził się kurs Dockera
Jest to dla nas temat odrębny i wręcz nietypowy. Bo z jednej strony nie planowaliśmy tego robić, bo wiele szkół internetowych to oferuje. Z drugiej strony sam prosił o swobodę i znalazł logiczne miejsce w naszej koncepcji szkolenia specjalistów IT w Kubernetesie.
Mówiąc bardzo globalnie, początkowo wszystko zaczęło się od kursu na Kubernetesie, kiedy to zaczęło się moim zdaniem dopiero po pierwszym Slurmie. Zebraliśmy opinie i zobaczyliśmy, że wiele osób chce przeczytać coś więcej o Dockerze gdzie indziej i w ogóle wiele osób przychodzi na podstawowy kurs Kubernetesa, nie wiedząc, co to jest .
Dlatego dla drugiego Slurmu zrobili kurs - a raczej nawet nie kurs, ale napisali kilka rozdziałów o Dockerach. Gdzie opowiadali o najbardziej podstawowych rzeczach, aby osoby przychodzące na zajęcia intensywne nie czuły się pokrzywdzone i ogólnie rozumiały, co się dzieje.
A potem wydarzenia potoczyły się mniej więcej w ten sposób. Ilość materiału rosła i po 3 dniach przestała pasować. I pojawił się logiczny i oczywisty pomysł: dlaczego by nie zamienić tego, co omawiamy w Slurm Basic, w jakiś mały kurs, na który można wysyłać osoby, które chcą obejrzeć coś o Dockerze, przed przystąpieniem do intensywnego kursu na Kubernetesie.
Slurm Junior to tak naprawdę połączenie kilku takich kursów podstawowych. W rezultacie kurs Docker stał się częścią Slum Junior. Oznacza to, że jest to taki krok zerowy wcześniej и . A potem były już tylko bardzo podstawowe abstrakcje.
W pewnym momencie ludzie zaczęli pytać: „Chłopaki, to wszystko jest super, to wystarczy, żeby zrozumieć, o czym się mówi na intensywnych kursach. Gdzie mogę przeczytać bardziej szczegółowo o tym, co potrafi doker, jak z nim pracować i co to jest?” Pojawił się więc pomysł, żeby to wyprostować , tak aby po pierwsze osoby, które przyjdą do Slurm za pomocą Kubernetesa, mogły zostać do niego jeszcze skierowane, a z drugiej strony po to, aby osoby, które na tym etapie rozwoju Kubernetesem nawet nie są zainteresowane. Aby informatyk mógł przyjść obejrzeć nasz kurs na Dockerze i rozpocząć swoją ewolucyjną drogę po prostu od czystego Dockera. Dzięki temu mamy taki pełnoprawny, kompletny kurs - i wtedy wielu po obejrzeniu tego kursu, po pewnym czasie pracy z czystym Dockerem, urosło do poziomu, w którym potrzebuje Kubernetesa lub innego systemu orkiestracji. A oni przyszli szczególnie do nas.
Czasem pojawia się pytanie: „Jaki ludzie mogą teraz nie potrzebować Kubernetesa?” Ale to pytanie nie dotyczy ludzi, jest raczej pytaniem o firmy. Tutaj trzeba zrozumieć, że Kubernetes ma pewne przypadki, w których dobrze się sprawdza i zadania, które dobrze rozwiązuje, ale wręcz przeciwnie, istnieją pewne scenariusze wykorzystania Kubernetesa, gdy powoduje to dodatkowy ból i dodatkowe cierpienie. Dlatego nie zależy to nawet od ludzi, ale od tego, jakie firmy się rozwijają i jak długo.
Na przykład jakiś okropny monolit Legacy – raczej nie warto wpychać go do Kubernetesa, bo przyniesie więcej problemów niż korzyści. Lub, na przykład, jeśli jest to mały projekt, ma małe obciążenie lub w zasadzie niewiele pieniędzy i zasobów. Nie ma sensu przeciągać tego do Kubernetesa.
I w ogóle, chyba w ogóle, jak wiele osób już mówiło, jeśli zadajesz sobie pytanie: „Czy potrzebuję Kubernetesa?”, to najprawdopodobniej go nie potrzebujesz. Nie pamiętam, kto pierwszy na to wpadł, moim zdaniem Pasha Selivanov. Zgadzam się z tym w 100%. A do Kubernetesa trzeba dorosnąć - a kiedy już stanie się jasne, że Kubernetes jest mi potrzebny i nasza firma go potrzebuje, a pomoże rozwiązać takie a takie problemy, to chyba warto iść się uczyć i dokładnie dowiedzieć się, jak ustawić dobrze to zaplanuj, aby proces przejścia na Kubernetes nie był bardzo bolesny.
O niektórych dolegliwościach dziecięcych i o kilku prostych, a nawet niezbyt prostych sprawach, można dowiedzieć się w szczególności u nas, a nie przechodzić przez własne cierpienie.
Wiele firm poszło dokładnie tą drogą, że na początku była tylko jakaś infrastruktura bez konteneryzacji. Potem doszli do punktu, w którym zarządzanie tym wszystkim stało się trudne, przeszli na Dockera i w pewnym momencie doszli do punktu, w którym stało się ciasno w ramach Dockera i tego, co oferuje. I zaczęli przyglądać się temu, co było wokół, jakie systemy rozwiązują te problemy, a w szczególności Kubernetes - to jeden z tych systemów, który pozwala rozwiązywać problemy, gdy czysty Docker staje się zatłoczony i brakuje mu funkcjonalności, jest to naprawdę dobry przypadek, gdy ludzie Idą krok po kroku od dołu do góry, rozumieją, że ta technologia nie wystarczy i przechodzą na wyższy poziom. Coś wykorzystali, znowu zaczęło ich brakować i ruszyli dalej.
To świadomy wybór – i to bardzo fajny.
Ogólnie widzę, że nasz system jest bardzo pięknie zbudowany, np. , nawet poprzez kursy wideo. Potem po oknie dokowanym idzie , a następnie , a następnie . Wszystko układa się logicznie – przechodzi człowiek i pojawia się solidny zawód.
W zasadzie zestaw kursów pozwala na pokrycie wielu przypadków, nawet współczesnych. Są jeszcze obszary, które pozostają szarą strefą, mam nadzieję, że wkrótce stworzymy pewne kursy, które pozwolą nam zamknąć te szare strefy, w szczególności wymyślimy coś o bezpieczeństwie. Ponieważ staje się to bardzo istotne.
Krótko mówiąc, mamy pewne szare obszary, które bardzo miło byłoby zamknąć, aby był to pełny, kompletny obraz - i ludzie mogliby przyjść i tak samo jak sam Kubernetes jest jak konstruktor Lego, można z niego robić różne rzeczy zbiera, jeśli nadal jest mało - uzupełnia, to samo z naszymi kursami, aby ludzie zrozumieli, czego z tego potrzebują; muszą ułożyć rodzaj układanki, rodzaj zestawu konstrukcyjnego z naszych kursów.
Jeśli zadasz sobie ogólnie poprawne i szczere pytanie: „Kto mógłby teraz skorzystać z aktywnego kursu Dockera?”, to:
- Dla studentów, którzy dopiero zaczynają się w to zagłębiać.
- Pracownicy działu testów.
- Tak naprawdę jest wiele firm, które nadal nie tylko nie korzystają z Dockera, ale nikt o takiej technologii nie słyszał i w zasadzie nie wie jak z niej korzystać. A znam kilka dużych firm w Petersburgu, które rozwijają się od wielu lat i korzystają ze starych technologii, idą w tym kierunku. W szczególności dla takich firm, dla inżynierów w takich firmach ten kurs może być bardzo interesujący, ponieważ po pierwsze pozwoli ci szybko zanurzyć się w tej technologii, a po drugie, gdy tylko pojawi się kilku inżynierów, którzy zrozumieją, jak to wszystko działa, mogą wnieść to do firmy i rozwijać tę kulturę oraz te kierunki w firmie.
- Moim zdaniem ten kurs może być nadal przydatny dla tych, którzy już pracowali z dockerem, ale bardzo mało, a bardziej w stylu „zrób raz, zrób dwa razy” - a teraz będą w jakiś sposób wchodzić w interakcję z tym samym Kubernetesem, a to nakłada na nich pewne obowiązki, jeśli masz bardzo powierzchowną wiedzę o tym, czym jest docker, jak go uruchomić, ale jednocześnie nie wiesz, jak to działa od środka, nie wiesz, co najlepiej z nim zrobić tego, a czego lepiej nie robić. W takim razie ten kurs doskonale nadaje się do usystematyzowania i pogłębienia wiedzy.
Ale jeśli masz wiedzę na poziomie: „Nie umiem poprawnie pisać tych samych plików Dockera, potrafię sobie wyobrazić, jakie są przestrzenie nazw, jak działają kontenery, jak faktycznie są one implementowane na poziomie systemu operacyjnego” – to nie ma problemu zdecydowanie nie ma sensu do nas chodzić, niczego nowego się nie dowiesz i będziesz trochę żałować wydanych pieniędzy i czasu.
Jeśli sformułujemy, jakie zalety ma nasz kurs, to:
- Staraliśmy się, aby ten kurs zawierał wystarczającą liczbę praktycznych przypadków, które pozwolą Ci nie tylko zrozumieć istniejącą część teoretyczną, ale także zrozumieć, dlaczego go potrzebujesz i jak wykorzystasz go w przyszłości;
- jest kilka sekcji, które bardzo rzadko można znaleźć gdziekolwiek - i ogólnie nie ma na nich zbyt wiele materiału. Dotyczą one interakcji Dockera z systemem operacyjnym, choć trochę inaczej. Jakie mechanizmy Docker wziął z systemu operacyjnego do wdrożenia systemu konteneryzacji - a to daje takie głębsze zrozumienie całego zagadnienia uruchamiania kontenerów w ramach systemu operacyjnego Linux. Jak to działa, jak współdziała ze sobą wewnątrz systemu operacyjnego, na zewnątrz i tak dalej.
To spojrzenie na tyle głębokie, że zdarza się dość rzadko, a jednocześnie moim zdaniem jest bardzo ważne. Jeśli chcesz dobrze zrozumieć jakąkolwiek technologię i wiedzieć, czego się po niej spodziewać, musisz przynajmniej mieć ogólne pojęcie o tym, jak ona działa na niskim poziomie.
Nasz kurs pokazuje i opowiada, jak to działa z punktu widzenia systemu operacyjnego. Z jednej strony wszystkie systemy konteneryzacji korzystają z tych samych mechanizmów systemu operacyjnego. Z drugiej strony biorą to, co jest w systemie operacyjnym Linux, takie jak doker. Inne systemy konteneryzacji nie wymyśliły niczego nowego - wzięli to, co było już w Linuksie i napisali po prostu wygodne opakowanie, które pozwala szybko to wywołać, uruchomić lub w jakiś sposób z nim wejść w interakcję. Ten sam Docker nie jest bardzo dużą warstwą pomiędzy systemem operacyjnym a linią poleceń, jest to rodzaj narzędzia, które pozwala nie pisać kiloton poleceń lub jakiegoś kodu C w celu utworzenia kontenera, ale zrobić to wpisując kilka linii w terminalu.
I jeszcze jedno, jeśli mówimy konkretnie o Dockerze, to tym, co Docker tak naprawdę wniósł do świata IT, są standardy. Jak aplikacja powinna zostać uruchomiona, jak powinna działać, jakie są wymagania dotyczące logów, jakie są wymagania dotyczące skalowania, konfiguracji samej aplikacji.
Pod wieloma względami okno dokowane dotyczy standardów.
Standardy również przenoszą się do Kubernetesa - i są dokładnie te same standardy; jeśli wiesz, jak dobrze uruchomić aplikację w Dockerze, w 99% przypadków będzie ona działać równie dobrze w Kubernetesie.
Jeśli zainteresował Cię nie tylko sposób powstania kursu Docker, ale także inne kursy, ale także sam kurs z praktycznego punktu widzenia, to
Będzie nam miło Cię widzieć!
Źródło: www.habr.com