Opinie czytelników
Obecnie brak opinii czytelników. Ocena opiera się na 2 głosach.
Oryginalny tytuł:
The DevOps 2.2 Toolkit
Zawartość książki:
Wydaje się, że z każdą nową książką zakres staje się coraz mniej precyzyjny. Kiedy zacząłem pisać Test-Driven Java Development, zakres całej książki był z góry ustalony. Pracował ze mną zespół. Zdefiniowaliśmy indeks i krótki opis każdego rozdziału. Od tego momentu pracowaliśmy zgodnie z harmonogramem, tak jak robi to większość autorów technicznych. Potem zacząłem pisać drugą książkę. Zakres był bardziej niejasny. Chciałem napisać o praktykach i procesach DevOps i miałem tylko bardzo szerokie pojęcie o tym, jaki będzie rezultat. Wiedziałem, że Docker musi się tam znaleźć. Wiedziałem, że zarządzanie konfiguracją jest koniecznością. Mikroserwisy, scentralizowane logowanie i kilka innych praktyk i narzędzi, których używałem w moich projektach, były częścią początkowego zakresu. W przypadku tej książki nie miałem za sobą nikogo. Nie było żadnego zespołu poza mną, mnóstwem pizzy, nieznaną liczbą puszek Red Bulla i wieloma nieprzespanymi nocami. Rezultatem jest „The DevOps 2. 0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices”. W przypadku trzeciej książki początkowy zakres stał się jeszcze bardziej niejasny. Zacząłem pisać bez planu. Miała być o zarządzaniu klastrami. Po kilku miesiącach pracy wziąłem udział w DockerCon w Seattle, gdzie zaprezentowano nam nowy tryb Docker Swarm. Moją natychmiastową reakcją było wyrzucenie wszystkiego, co napisałem do kosza i rozpoczęcie od nowa. Nie wiedziałem, o czym będzie książka, poza tym, że musi to być coś o Docker Swarm.
Byłem pod wrażeniem nowego projektu. Coś w Swarm skończyło się jako „The DevOps 2. 1 Toolkit: Docker Swarm: Budowanie, testowanie, wdrażanie i monitorowanie usług w klastrach Docker Swarm”. Podczas pracy nad nim postanowiłem stworzyć serię DevOps Toolkit. Pomyślałem, że byłoby wspaniale zapisać moje doświadczenia z różnych eksperymentów oraz ze współpracy z różnymi firmami i projektami open source. Tak więc, naturalnie, zacząłem myśleć i planować trzecią część serii; „The DevOps Toolkit 2. ”2. Jedynym problemem jest to, że tym razem, szczerze mówiąc, nie miałem pojęcia, o czym to będzie. Jednym z pomysłów było dogłębne porównanie różnych schedulerów (np. Docker Swarm, Kubernetes i Mesos/Maraton). Innym było zbadanie serverless. Mimo że jest to okropna nazwa (istnieją serwery, po prostu nimi nie zarządzamy), jest to świetny temat. Pomysły wciąż napływały, ale nie było wyraźnego zwycięzcy. Postanowiłem więc nie definiować zakresu. Zamiast tego zdefiniowałem kilka ogólnych celów.
Celem, który sobie postawiłem, było zbudowanie samoadaptującego się i samonaprawiającego się systemu opartego na Dockerze. Kiedy zacząłem pisać tę książkę, nie wiedziałem, jak to zrobię. Istniały różne praktyki i narzędzia, których używałem, ale nie było widocznego światła na końcu tunelu. Zamiast definiować, czym będzie ta książka, zdefiniowałem, co chcę osiągnąć. Możesz myśleć o tej książce jako o moim zapisie podróży. Musiałem wiele odkryć. Musiałem zaadoptować kilka nowych narzędzi i samemu napisać trochę kodu. Potraktuj tę książkę jako „pamiętnik Viktora, który próbuje robić różne rzeczy”.
Celem jest wyjście poza prostą konfigurację klastra, usług, ciągłego wdrażania i wszystkich innych rzeczy, które prawdopodobnie już znasz. Jeśli nie, przeczytaj moje starsze książki.
