Uczestnik przychodzi na kurs lub intensyw. Widzi uporządkowane linie wsparcia technicznego, starannie ułożone kable zasilające, szachowy porządek sali wykładowej, barwne obrazy i schematy slajdów. Prelegenci z żartami i uśmiechami przekazują informacje tak, że tylko trzeba się w nie wkręcać. Stoiska są gotowe, zadania z praktyki po prostu same wylatują z palców, chyba że czasami potrzebna jest pomoc wsparcia technicznego.
A także przerwy kawowe z podobnie myślącymi osobami, energiczna i pełna życia atmosfera, wymiana doświadczeń, najnieoczekiwane pytania do prelegentów. Odpowiedzi i informacje, których nie znajdziesz w podręcznikach, ale tylko w praktyce.
Jak myślicie, ile czasu, wysiłku i nerwów poszło, żeby to wyglądało dokładnie tak?
Dziękujemy Włodzimierzowi Guriwanowowi, certyfikowanemu administratorowi Kubernetes i inżynierowi/team leaderowi w Southbridge, który od samego początku był świadkiem i aktywnym uczestnikiem tworzenia wielu kursów Slurm.
Widział on kulisy tworzenia kursów - trudności i kolczaste pułapki, wnioski i nieoczekiwane rozwiązania. I już znane intensywy po Kubernetes, takie jak Slurm Podstawowy i Slurm Mega. I nowy, w wielu aspektach przerobiony kurs , który nieuchronnie nadchodzi i rozpocznie się 19 sierpnia.
Ale, chyba wystarczy liryk, przejdźmy do samej historii. Jak z pary tematów intensywu stopniowo wyrosło w pełni samowystarczalne i wieloaspektowe . Więc zacznę opowieść o tym, jak tworzone są i rozwijają kursy - wręcz "Dawno, dawno temu w odległej galaktyce..."
A co jest tam za kulisami?
Jeśli zapytasz, jak robimy kursy i od czego wszystko się zaczyna, odpowiem krótko: "Wszystko zaczyna się od pomysłu".
Zazwyczaj pomysł przychodzi skądś - nie siedzimy przykuci kajdanami w piwnicy, czekając aż wymyślimy: «A na jaki temat zrobimy kurs?». Pomysły przychodzą same z zewnętrznych źródeł. Czasami ludzie zaczynają aktywnie pytać: «A co wiecie o takiej konkretnej technologii?». Albo jak to było z Dockerem, że nie udawało się go pomieścić w czasie intensywu - trzeba go było oczywiście wynieść na zewnątrz, żeby w ramach intensywu móc coś o nim opowiedzieć.
Właśnie w ten sposób pojawia się pomysł.
Po tym, jak się pojawiła, zaczyna się, moim zdaniem, najtrudniejszy moment — w ogóle zrozumieć, co właściwie włączyć do tego kursu — to jest bardzo porównywalne z tym, jak przygotowują się mówcy na różne konferencje.
Jest tam jedna główna bolączka, kiedy wybierasz temat i myślisz: „A co o nim opowiedzieć? To zbyt proste, to oczywiste, to też wszyscy wiedzą.”
Ale tak naprawdę wcale nie jest. I ja osobiście bardzo często mówię, że to, co wydaje się oczywiste dla ciebie, dla tych, którzy przyjdą cię słuchać lub przechodzić kurs, wcale nie jest oczywiste. I tutaj pojawia się duża ilość pracy oraz wewnętrzny konflikt, co właściwie włączyć do kursu. W efekcie powstaje lista rozdziałów, bardziej zdecydowanych i dużymi pociągnięciami, o czym będzie kurs.
A potem zaczyna się prosta rutynowa praca:
- Dobór materiałów
- Uważne czytanie dokumentacji bieżącej wersji, ponieważ świat IT rozwija się w tempie kosmicznym. Nawet jeśli pracujesz nad czymś i robisz o tym kurs, musisz zajrzeć do dokumentacji i zobaczyć, co nowego się pojawiło, co warto opowiedzieć, co może być szczególnie przydatne do wspomnienia.
- I pojawia się pewien szkielet kursu, gdzie już większość tematów jest właściwie rozpisana i wydaje się, że trzeba tylko nagrać filmy i wprowadzić je do produkcji.
- Ale w rzeczywistości nie, zaczyna się ciężka praca, ale nie dla autorów kursu, a dla tych, którzy testują. Zazwyczaj naszymi alfa-testerami jest wsparcie techniczne, które, po pierwsze, sprawdza kursy pod kątem różnych błędów syntaktycznych i gramatycznych. Po drugie, mocno nas krytykują i narzekają, gdy są jakieś zupełnie nieoczywiste, niezrozumiałe miejsca. Kiedy w tekstach pojawiają się jakieś złożone zdania z podrzędnymi, zajmujące kilka stron lub oczywiste bzdury. Oni wszystko to sprawdzają, wyszukują.
- Następnie zaczyna się etap testowania praktyki, w którym również dostrzegane są oczywiste problemy i wskazywane są momenty, które można by uprościć, ponieważ samo kopiowanie staje się dość nieciekawe - a pojawiają się miejsca, w których wymagamy od ludzi wiele, którzy będą uczestniczyć w tym kursie. Wtedy nadchodzą rekomendacje: „Zróbcie to, chłopaki, tutaj prościej, będzie to łatwiej przyswajalne i przyniesie większe korzyści.”
- Po wykonaniu tej pracy, napisaniu części dotyczącej wideo, wszystko wydaje się w porządku. Można już oddać to do publikacji, do reklamy tego kursu. Ale znów nie, za wcześnie - ponieważ ostatnio przestaliśmy trochę ufać sobie i zaczęliśmy bardziej polegać na informacjach zwrotnych. Pojawiło się coś takiego jak beta-testowanie - to kiedy zaprasza się ludzi, którzy są całkowicie obcy, niezwiązani z naszą firmą i z jakimiś bonusami pokazuje się im wszystkie części kursu, wideo, teksty, zadania praktyczne, aby ocenili jakość materiału, dostępność materiału i pomogli nam stworzyć kurs jak najlepiej.
- I gdy przechodzi się przez kilka takich iteracji, przez mówców, alfa-testowanie w formie wsparcia technicznego, beta-testowanie, poprawki. A potem wszystko zaczyna się od nowa - wsparcie techniczne, beta-testowanie, poprawki.
- W pewnym momencie przychodzi zrozumienie, że albo kończymy z poprawkami, ponieważ stworzenie czegoś, co podoba wszystkim – jest całkowicie nierealne, albo podejmowane są jakieś radykalne decyzje. Gdy wiele uwag dotyczących pewnych miejsc jest krytycznych – trzeba je globalnie przearanżować, ponieważ coś poszło nie tak.
- Następnie przychodzi czas na drobne poprawki - gdzieś zdanie nie jest zbyt ładnie sformułowane, gdzieś komuś nie podoba się czcionka 14,5, a chciałby 15,7.
- Kiedy pozostają tego typu uwagi, to wszystko, kurs w miarę się otwiera, zaczynają się oficjalne sprzedaże.
I na pierwszy rzut oka krótka i prosta zadanie stworzenia kursu okazuje się nie być wcale prostym i zajmuje niewiarygodnie dużo czasu.
I jest jeszcze jeden istotny punkt, że praca z kursem nie kończy się w momencie jego wydania. Po pierwsze, uważnie czytamy komentarze, które pozostawiają użytkownicy do poszczególnych części. I mimo że włożyliśmy w to ogromny wysiłek, nadal wychwytywane są jakieś błędy, które na bieżąco są poprawiane, aby każdy kolejny użytkownik otrzymał lepszą jakość usług.
Każdy kurs ma swojego właściciela produktu, który oprócz tego, że określa ogólną koncepcję i sprawdza terminy, robi notatki na marginesach, co gdy nadejdzie czas na całkowite przepisanie kursu, a to na pewno nastąpi, bo za dwa lata, a może i za rok, część tego, co przedstawiamy, stanie się nieaktualna po prostu dlatego, że zestarzeje się moralnie. Właściciel produktu robi notatki na marginesach, co najczęściej ludzie pytają, jakie momenty były niejasne, jakie zadania wydawały się bardzo trudne, a które z kolei były, przeciwnie, bardzo proste. I to wszystko bierze się pod uwagę przy ponownym nagrywaniu kursu, przy jakimś refaktoryzowaniu, aby każda nowa iteracja kursu stawała się lepsza, bardziej wygodna i komfortowa.
Tak właśnie powstają kursy.
Jak powstał kurs dotyczący Dockera
To odrębny, a nawet nietypowy temat dla nas. Z jednej strony nie planowaliśmy go stworzyć, ponieważ wiele szkół internetowych go oferuje. Z drugiej strony, sam się narzucił i znalazł logiczne miejsce w naszej koncepcji kształcenia specjalistów IT w zakresie Kubernetes.
Jeśli mówić bardzo ogólnie, to wszystko zaczęło się od kursu dotyczącego Kubernetes, kiedy tylko zaczęliśmy, wydaje mi się, po pierwszym Słörmie. Zebraliśmy opinie zwrotne i zauważyliśmy, że wiele osób chce jeszcze gdzieś dodatkowo poczytać o Dockerze i w ogóle wiele osób przychodzi na podstawowy kurs dotyczący Kubernetes, nie wiedząc, czym on właściwie jest. .
Dlatego na drugi Słörm zrobiliśmy kurs — a właściwie nie kurs, a zrobiliśmy kilka rozdziałów o Dockerze. Gdzie tłumaczyliśmy najprostsze rzeczy, aby ludzie, którzy przychodzą na intensywne szkolenie, nie czuli się niedowartościowani i w ogóle rozumieli, co się dzieje.
A potem wydarzenia rozwijały się tak. Liczba materiałów rosła i przestała mieścić się w 3 dni. Pojawił się logiczny i oczywisty pomysł: dlaczego nie stworzyć z tego, co mówimy na Slurm Basic, jakiegoś małego kursu, na który można by wysyłać ludzi, którzy przed intensywnym kursem o Kubernetes chcą zobaczyć coś o Dockerze.
Slurm Junior to w zasadzie połączenie kilku takich podstawowych kursów. W rezultacie kurs o Dockerze stał się częścią Slurm Junior. To znaczy, że to taka zerowa stacja przed i . A potem były tam naprawdę podstawowe abstrakcje.
W pewnym momencie ludzie zaczęli pytać: „Hej, to wszystko jest świetne, wystarczające, aby zrozumieć, co mówicie na intensywach. Gdzie można poczytać więcej o tym, co potrafi Docker, jak z nim pracować i co w ogóle przedstawia?”. Tak pojawił się pomysł, aby zrobić z niego , aby, po pierwsze, można było dalej wysyłać tam ludzi, którzy przychodzą na Slurm o Kubernetes, a z drugiej strony, dla tych, których na tym etapie rozwoju Kubernetes nawet to nie interesuje. Aby specjalista IT mógł przyjść, zobaczyć nasz kurs o Dockerze i zacząć swoją drogę ewolucyjną po prostu od czystego Dockera. Żebyśmy mieli taki pełnoprawny, kompletny kurs, a wielu, po zobaczeniu tego kursu, pracując przez jakiś czas z czystym Dockerem, wzrosło do takiego poziomu, kiedy już potrzebowali Kubernetes lub innego systemu orkiestracji. I w szczególności przyszli do nas.
Czasami pada pytanie: „A jakim osobom teraz Kubernetes może się nie przydać?” Ale to pytanie nie dotyczy ludzi, to raczej pytanie o firmy. Trzeba zrozumieć, że Kubernetes ma określone przypadki, gdzie dobrze się sprawdza i zadania, które dobrze rozwiązuje, a są też wręcz przeciwnie, jakieś scenariusze użycia Kubernetes, kiedy on przynosi dodatkowy ból i dodatkowe cierpienia. Dlatego to nawet nie zależy od ludzi, ale od tego, co i jak długo rozwijają firmy.
Na przykład, jakiś przestarzały monolit Legacy — prawdopodobnie nie warto go wprowadzać do Kubernetes, ponieważ spowoduje to więcej problemów niż korzyści. Albo na przykład, jeśli to mały projekt — ma niskie obciążenia lub w ogóle niewiele pieniędzy i zasobów. W takim przypadku nie ma sensu wprowadzać go do Kubernetes.
Ogólnie rzecz biorąc, jak już wielu mówiło, jeśli zadajesz sobie pytanie: „Czy potrzebuję Kubernetes?”, to prawdopodobnie go nie potrzebujesz. Nie pamiętam, kto to pierwszy wymyślił, chyba Pasha Selivanov. Zgadzam się z tym w 100%. Trzeba „dorosnąć” do Kubernetes — a kiedy już zrozumiesz, że naprawdę go potrzebujesz, że przyniesie korzyści naszej firmie, wtedy warto uczyć się, jak dobrze go skonfigurować, aby proces przejścia na Kubernetes nie był bardzo bolesny.
Jakieś tam dziecięce dolegliwości i pewne bardzo proste rzeczy, a nawet nie takie proste, można poznać w szczególności u nas, zamiast przechodzić przez własne pułapki i ból.
Wiele firm przeszło przez drogę, że na początku miały jakąś po prostu infrastrukturę bez konteneryzacji. Potem zaczęło być trudno tym wszystkim zarządzać, przeszły na dockery, a w pewnym momencie doszły do stanu, w którym w ramach dockera i tego, co on oferuje, staje się ciasno. Zaczęli więc się rozglądać, jakie systemy rozwiązują te problemy, a Kubernetes to jeden z takich systemów, które pozwalają rozwiązywać problemy, gdy czysty docker staje się ciasny i brakuje funkcjonalności. To bardzo dobry przypadek, kiedy ludzie idą od dołu do góry, etapami, rozumiejąc, że ta technologia jest niewystarczająca, i przechodzą na wyższy poziom. Spróbowali czegoś, znowu okazało się, że to za mało — więc idą dalej.
To świadomy wybór — i to jest naprawdę świetne.
Widzę, że nasz system bardzo ładnie się układa, na przykład , nawet w formie kursów wideo. Potem po dockerze idzie , potem , potem . Wszystko układa się logicznie — człowiek przechodzi i zdobywa kompletną profesję.
W zasadzie zestaw kursów pozwala zamknąć bardzo wiele przypadków, naprawdę współczesnych. Są jeszcze obszary, które pozostają szare, mam nadzieję, że wkrótce stworzymy jakieś kursy, które pozwolą zamknąć te szare obszary, w szczególności wymyślimy coś na temat bezpieczeństwa. Ponieważ to staje się bardzo aktualne.
Krótko mówiąc, mamy pewne szare obszary, które byłoby bardzo dobrze zamknąć, aby to była naprawdę spójna całość — i ludzie mogli przyjść, a sam Kubernetes przedstawia się jako konstruktor LEGO, z którego można budować różne rzeczy, jeśli czegoś brakuje — uzupełniać, tak samo z naszymi kursami, aby ludzie mogli rozumieć, czego potrzebują, i zbierać pewną układankę, pewien konstruktor z naszych kursów.
Jeśli zadać sobie właściwe i szczere pytanie: „Kto będzie teraz potrzebował aktywnego kursu Docker?”, to:
- Studentom, którzy dopiero zaczynają się zagłębiać.
- Pracownikom działu testowania.
- Tak naprawdę jest wiele firm, w których wciąż nie tylko nie używają Dockerów, ale nikt nie słyszał o tej technologii i w zasadzie nie wie, jak ją wykorzystać. I wiem o kilku dużych firmach w Petersburgu, które zajmują się tworzeniem od wielu lat, i one dalej korzystają z jakichś 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ć naprawdę interesujący, ponieważ po pierwsze pozwoli szybko zanurzyć się w tę technologię, a po drugie, gdy tylko pojawi się kilku inżynierów, którzy rozumieją, jak to wszystko działa, mogą to wprowadzać do firmy i rozwijać tę kulturę oraz te kierunki wewnątrz firmy.
- Moim zdaniem, ten kurs może być również przydatny dla tych, którzy już pracowali z Dockerem, ale bardzo niewiele i bardziej w stylu „zrób jeden, zrób dwa” — a teraz zamierzają w ten czy inny sposób współpracować z tym samym Kubernetesem, co nakłada na nich pewne zobowiązania, jeśli mają zupełnie powierzchowne wiedzę na temat tego, czym jest Docker, jak go uruchamiać, ale jednocześnie nie wiedzą, jak to działa od środka, nie wiedzą, co lepiej z nim robić, a czego lepiej unikać, wtedy ten kurs dobrze nadaje się do systematyzacji i pogłębiania wiedzy.
Ale jeśli twoje umiejętności są na poziomie: „Nie wiem, jak poprawnie pisać pliki dockerowe, mam pojęcie, czym są namespace'y, jak działają kontenery oraz jak są one rzeczywiście zaimplementowane na poziomie systemu operacyjnego”, to zdecydowanie nie ma sensu przychodzić do nas, nie dowiesz się niczego nowego i będzie trochę smutno z powodu wydanych pieniędzy i straconego czasu.
Jeśli zdefiniować, jakie zalety ma nasz kurs, to:
- staramy się, aby ten kurs miał wystarczającą liczbę praktycznych przypadków, które pozwolą ci nie tylko zrozumieć teoretyczną część, która jest, ale także zrozumieć, po co to jest potrzebne i jak to wykorzystasz w przyszłości;
- znajdziesz tam kilka rozdziałów, które niezwykle rzadko się spotyka — i w ogóle nie ma na ten temat zbyt wielu materiałów. Odnoszą się one do interakcji dockera z systemem operacyjnym, nawet nieco inaczej. Jakie mechanizmy docker przejął od systemu operacyjnego, aby zrealizować system konteneryzacji — i to daje głębsze zrozumienie całego problemu uruchamiania kontenerów w ramach systemu operacyjnego Linux. Jak to działa, jak funkcjonuje współpraca wewnątrz systemu operacyjnego, na zewnątrz i tak dalej.
To bardzo głęboki wgląd, który jest dość rzadko spotykany, a moim zdaniem jest to bardzo istotne. Jeśli chcesz dobrze zrozumieć jakąkolwiek technologię i wiedzieć, czego się po niej spodziewać, musisz przynajmniej ogólnie wyobrażać sobie, jak działa na niskim poziomie.
Nasz kurs pokazuje i wyjaśnia, jak to wygląda z perspektywy systemu operacyjnego. Z jednej strony, wszystkie systemy konteneryzacji wykorzystują te same mechanizmy systemu operacyjnego. Z drugiej strony, korzystają z tego, co jest w systemie operacyjnym Linux, jak docker. Inne systemy konteneryzacji nie wymyśliły nic nowego — przejęły to, co już istnieje w Linuxie i napisały tylko wygodną nakładkę, która pozwala szybko to wywoływać, uruchamiać lub w jakiś sposób z tym współdziałać. Sam docker to nie bardzo duża warstwa między systemem operacyjnym a wierszem poleceń, to taki narzędzie, które pozwala nie pisać ton komend, czy jakiegoś kodu w C, aby stworzyć kontener, lecz zrealizować to, wprowadzając kilka linijek w terminalu.
A co więcej, jeśli mówimy konkretnie o dockerze, to co naprawdę wniosło docker do świata IT, to standardy. Jak powinno być uruchamiane aplikację, jak powinna działać, jakie są wymagania dotyczące logów, jakie są wymagania dotyczące skalowania i konfigurowania samej aplikacji.
W dużej mierze docker to standardy.
Standardy te przenoszą się także do Kubernetes – i tam są dokładnie te same standardy; jeśli potrafisz dobrze uruchomić swoją aplikację w dockerze, to w 99% będzie ona działać równie dobrze w Kubernetes.
Jeśli jesteś zainteresowany nie tylko tym, jak powstał kurs Docker, ale także innymi kursami, a także samym kursem z perspektywy praktycznej, to
Będziemy wdzięczni za Twoją obecność!
Źródło: habr.com
