參與者參加課程或強化課程。他看到一排排有序的技術支援、整齊佈線的電源線、棋盤式佈局的報告廳、明亮的圖片和幻燈片圖表。演講者充滿笑話和微笑，以一種讓你有時間理解的方式傳遞訊息。看台已經搭好，練習任務就在你的指尖，只是有時你需要技術人員的幫助。支持。
還有與志趣相投的人一起喝咖啡休息，歡快而充滿活力的氛圍，交流經驗，提出演講者最意想不到的問題。您在手冊中找不到答案和訊息，只能在實踐中找到。
你認為需要多少時間、精力和精力才能讓它看起來一模一樣？
感謝南橋認證的 Kubernetes 管理員和工程師/團隊負責人 Volodya Guryanov，他從一開始就見證並積極參與了許多 Slurm 課程的創建。
他看到了課程創作的弱點——複雜性和棘手的問題、洞察力和意想不到的解決方案。還有我們已經熟悉的 Kubernetes 密集課程，例如 Slurm Basic 和 Slurm Mega。以及一門經過大幅修改的新課程 ，它無情地臨近，並將於19月XNUMX日開始。
但是，也許歌詞已經說得夠多了，讓我們繼續討論故事本身。如何從幾個密集的主題中形成一個完全自給自足且多面向的主題 。所以我將從如何創建和開發課程的故事開始 - 就像“很久以前，在一個遙遠的星系...”
幕後到底是什麼？
如果你問我們如何製作課程以及一切從哪裡開始，我會簡單地回答「一切都始於一個想法」。
通常這個想法來自某個地方——我們不會被戴上手銬坐在地下室，直到我們想出：“我們應該開設什麼主題的課程？”想法來自外部來源。有時人們開始主動問：“你對某某特定技術了解多少？”或者說，對於 Docker 來說，不可能讓他適應密集課程的時間——他顯然必須被帶到外面，以便有時間在密集課程中講一些東西。
這就是一個想法的出現。
在我看來，宣布之後，最困難的時刻就開始了——總體上理解本課程要包含哪些內容——這與演講者為任何會議做準備的方式非常相似。
當你似乎選擇了一個主題並思考：「我能告訴你什麼？這太簡單了，這是顯而易見的，大家也都知道。
但事實上根本不是這樣的。我個人在很多地方都說過，對於你、那些來聽你演講或參加課程的人來說，看似顯而易見的事情其實並不明顯。這裡就出現瞭如此大的工作層級和內部衝突，即課程包含哪些內容。結果，我們得到了這樣一個章節列表，內容如此籠統，課程將講述什麼內容。
然後簡單的日常工作就開始了：
- 材質選擇
- 請仔細閱讀當前版本的文檔，因為 IT 世界現在正在以某種宇宙速度發展。即使您正在研究某些東西並製作有關它的課程，您也必須查看文件並查看其中的新內容，有哪些值得討論的內容，以及可能特別有用的內容。
- 課程的某個框架出現了，其中大多數主題一般都已經涵蓋了，而且似乎無論有什麼 - 錄製視頻並將其投入生產。
- 但事實上，不，那麼艱苦的工作就開始了，但不是針對課程的作者，而是針對那些測試的人。通常我們的 alpha 測試人員是技術支援人員，首先校對課程中的任何句法和語法錯誤。其次，當我們遇到一些完全不明顯、難以理解的地方時，他們就會用棍棒打我們，使我們痛苦不堪。當文本中出現一些結構複雜、長達幾頁的從句或明顯的廢話時。他們全部閱讀並留意。
- 然後練習測試階段開始，一些明顯的不工作的東西也被捕獲，並且顯示一些可以變得更加困難的時刻，因為它變得不是很有趣 - 只是坐著和復制 - 並且確定了非常重要的地方困難，我們有很多事情要做，我們希望那些參加這門課程的人能夠做到這一點。然後建議就來了：“夥計們，把這裡弄得更簡單一些，這樣會更容易被感知，也會從中得到更多好處。”
- 做完這麼多工作，與影片相關的部分就寫好了，一切似乎都順利了。您已經可以將其捐贈用於製作、宣傳本課程。但同樣，不，現在還為時過早 - 因為最近我們已經不再相信自己了，原則上，我們已經開始更多地利用反饋進行工作。有一種東西叫做 beta 測試 - 這是當人們被外部邀請時，與我們公司沒有任何联系，並且為了一些好東西，他們會看到課程的所有部分，視頻，文本，實踐任務，以便他們評估材料的品質、材料的可獲取性，並幫助我們使課程盡可能好。
- 當經歷幾次這樣的迭代時，揚聲器、技術支援形式的 alpha 測試、beta 測試、改進。然後一切重新開始——技術支援、beta 測試、改進。
- 在某些時候，我們會認識到，要么我們完成修改，因為確保每個人都喜歡它是完全不切實際的，要么做出一些重大決定。當對某些地方的許多評論很關鍵時，請在全球範圍內重做它們，因為出了問題。
- 然後就到了進行小修改的時候了——在某個地方，句子的表述不太好，在某個地方，有人不喜歡字體 14,5，但想要 15,7。
- 當這種評論仍然存在時，就這樣，課程或多或少地打開了，正式銷售開始了。
乍一看，創建課程這個簡短的任務一點也不簡單，而且需要非常長的時間。
還有一點很重要，課程發布後，課程的工作還沒結束。首先，我們仔細閱讀了某些部分留下的評論。儘管我們付出了所有的努力，但仍然發現了一些缺陷，一些錯誤正在被即時糾正和改進，以便每個後續用戶都能得到更好的服務。
每門課程都有自己的產品負責人，除了定義總體概念外，他還會檢查截止日期，並在頁邊空白處做筆記，表明當需要完全重寫課程時，它肯定會到來，因為在兩年內，甚至一年後，我們所說的一些內容將變得無關緊要，僅僅因為它們在道德上變得過時。產品負責人在頁邊空白處做了筆記，大多數人經常會問哪些要點不清楚，哪些任務看起來非常困難，哪些任務相反看起來非常簡單。所有這些都在重新錄製課程時、在某種重構過程中考慮在內，以便全局課程的每次迭代都變得更好、更方便和舒適。
這就是課程的出現方式。
Docker 課程是如何誕生的
這對我們來說是一個單獨的、甚至不尋常的話題。因為一方面，我們本來沒有打算這樣做，因為很多線上學校都提供它。另一方面，他自己要求自由，並在我們用 Kubernetes 培訓 IT 專家的理念中找到了合理的位置。
從全球範圍來看，最初這一切都是從 Kubernetes 課程開始的，在我看來，它是在第一個 Slurm 之後才開始的。我們收集了回饋，發現許多人想在其他地方閱讀有關 Docker 的其他內容，而且一般來說，許多人在不知道 Kubernetes 是什麼的情況下就開始學習 Kubernetes 基礎課程 .
因此，對於第二個 Slurm，他們製作了一門課程——或者更確切地說，甚至不是一門課程，而是製作了幾個關於 Docker 的章節。他們告訴了一些最基本的事情，這樣來強化班的人就不會感到被剝奪，通常會理解正在發生的事情。
然後事情的發展大致上是這樣的。材料量增加並在 3 天內停止安裝。於是出現了一個合乎邏輯且顯而易見的想法：為什麼不將我們在Slurm Basic 中介紹的內容轉變為某種小型課程，您可以讓想要觀看有關Docker 的人員參加該課程，然後再參加有關Kubernetes 的強化課程。
事實上，Slurm Junior 就是幾門這類基礎課程的組合。結果，Docker 課程成為了 Slurm Junior 的一部分。也就是說，這之前是這樣的零步 и 。然後只有非常基本的抽象。
在某些時候，人們開始問：「夥伴們，這一切都很棒，這足以理解你們在密集課程中談論的內容。我可以在哪裡更詳細地了解 docker 可以做什麼、如何使用它以及它是什麼？所以就想出了一個方法來解決這個問題 這樣，一方面，使用 Kubernetes 來 Slurm 的人仍然可以被送到它，另一方面，對於那些在現階段對 Kubernetes 甚至不感興趣的人來說。這樣，IT 專家就可以觀看我們的 Docker 課程，並從純粹的 Docker 開始他的進化之路。這樣我們就有了這樣一個成熟、完整的課程——然後很多人在觀看了這個課程、使用純 Docker 工作了一段時間之後，已經發展到了需要 Kubernetes 或其他一些編排系統的水平。他們特別來找我們。
有時會問：“現在什麼樣的人可能不需要 Kubernetes？”但這不是人的問題，而是企業的問題。這裡你需要明白，Kubernetes 在某些情況下非常適合它，並且可以很好地解決任務，但相反，在某些場景下使用 Kubernetes 會帶來額外的痛苦和額外的痛苦。因此，它甚至不取決於人，而是取決於公司發展了什麼以及發展了多久。
例如，一些可怕的遺留巨石 - 你可能不應該將其推入 Kubernetes，因為它會導致更多的問題而不是好處。或者，例如，如果這是一個小項目，它的負載很小，或者原則上沒有很多資金和資源。將其拖到 Kubernetes 中是沒有意義的。
一般來說，可能，正如許多人已經說過的那樣，如果你問這個問題：“我需要 Kubernetes 嗎？”，那麼很可能你不需要它。我不記得是誰第一個提出這個想法的，我認為是帕夏·塞利瓦諾夫（Pasha Selivanov）。我百分百同意這一點。你需要成長到 Kubernetes - 當我已經清楚地知道我需要 Kubernetes 並且我們公司需要它，並且它將有助於解決這樣那樣的問題時，那麼去學習並弄清楚如何設置可能是有意義的做好了，這樣切換到Kubernetes 的過程就不會很痛苦了。
孩子的一些小病，一些簡單的事情，甚至不是很簡單的事情，都可以從我們這裡特別找出來，而不用自己去費力和痛苦。
許多公司的做法完全一樣，最初只有某種基礎設施，沒有容器化。然後他們到了管理這一切變得困難的地步，他們轉向了 Docker，在某個時候，他們發展到了在 Docker 及其提供的框架內變得局促的地步。他們開始研究周圍的情況，什麼系統可以解決這些問題，特別是Kubernetes——當純Docker 變得擁擠且缺乏功能時，這是一個可以讓你解決問題的系統，這是一個非常好的案例，當人們他們從下到上一步步前進，明白這項技術還不夠，並進入下一個層次。他們使用了一些東西，它又變得稀缺了，然後他們繼續前進。
這是一個有意識的選擇——而且非常酷。
總的來說，我發現我們的系統建構得非常漂亮，例如， ，甚至透過視訊課程。然後在 docker 之後它就走了 ， 然後 ， 然後 。一切都按邏輯排列——一個人過去了，一個紮實的職業出現了。
原則上，這套課程可以讓你涵蓋許多案例，甚至是現代案例。仍然有一些領域仍然是灰色區域，我希望我們很快就會創建一些課程，使我們能夠關閉這些灰色區域，特別是我們將提出一些有關安全的內容。因為這變得非常重要。
簡而言之，我們有一些灰色區域，最好關閉它們，這樣它就會是一個完整的、完整的圖景——人們可以來，就像Kubernetes 本身就像一個樂高構造器一樣，你可以用它來製作不同的東西如果還不夠的話，它會收集——補充，就像我們的課程一樣，這樣人們就可以從中了解他們需要什麼，他們需要從我們的課程中組裝出一種拼圖，一種構建集。
如果您問自己一個大致正確且誠實的問題：“現在誰可以使用活躍的 Docker 課程？”，那麼：
- 對於剛開始接觸這個領域的同學來說。
- 測試部門員工。
- 事實上，仍然有許多公司不僅沒有使用Docker，而且沒有人聽說過這種技術，原則上也不知道如何使用它。而且我知道聖彼得堡的幾家大公司已經發展了很多年了，他們使用了一些舊的技術，他們正在朝這個方向發展。特別是對於這樣的公司，對於這樣的公司的工程師來說，這個課程可能會非常有趣，因為，首先，它可以讓你快速沉浸在這項技術中，其次，一旦有幾個工程師出現，他們就知道這一切是如何進行的。
- 在我看來，這門課程對於已經使用過docker 的人來說可能仍然有用，但在「做一次，做兩次」風格中很少而且更多——現在他們將以某種方式與同一個Kubernetes 進行交互，而這個對他們施加了一定的義務，如果你對docker 是什麼、如何運行它只有非常膚淺的了解，但同時你不知道它從內部是如何工作的，你不知道最好用什麼來處理什麼是最好不要做，那麼這門課程非常適合系統化和深化知識。
但是，如果您具有以下級別的知識：“我不知道如何正確編寫相同的 Docker 文件，我可以想像名稱空間是什麼，容器如何工作，它們在操作系統級別如何實際實現” - 那麼就有了去我們這裡絕對沒有意義，你不會學到任何新東西，而且你會為所花費的金錢和時間感到有點難過。
如果我們明確我們的課程有哪些優勢，那麼：
- 我們試著讓這門課程有足夠數量的實際案例，讓你不僅能夠理解現有的理論部分，還能理解為什麼你需要它以及將來如何使用它；
- 有幾個部分在任何地方都很少見——而且一般來說，關於它們的材料並不多。它們與 Docker 與作業系統的互動有關，甚至略有不同。 Docker 從作業系統中採用了哪些機制來實現容器化系統，這讓我們對在 Linux 作業系統中運行容器的整個問題有了更深入的了解。它如何運作，如何在作業系統內部、外部相互交互，等等。
這是一種真正深入的觀察，很少發生，但同時，在我看來，它非常重要。如果你想很好地理解任何技術並了解它的期望，你至少需要對它在低層次上如何運作有一個總體了解。
我們的課程從操作系統的角度展示並講述了它是如何工作的。一方面，所有容器化系統都使用相同的作業系統機制。另一方面，他們採用了 Linux 作業系統中的東西，例如 docker。其他容器化系統並沒有提出任何新東西——它們採用了 Linux 中已有的東西，只編寫了一個方便的包裝器，允許您快速調用它、運行它或以某種方式與其互動。同樣的Docker 並不是作業系統和命令列之間的一個非常大的層，它是一種實用程序，允許您不必編寫數千個命令或某種C 程式碼來創建容器，而是透過輸入來完成此操作終端中的幾行。
還有一件事，如果我們具體談論 Docker，Docker 真正為 IT 世界帶來的是標準。應用程式應該如何啟動，應該如何工作，日誌有什麼要求，擴展有什麼要求，配置應用程式本身。
在很多方面，docker 都是關於標準的。
標準也在轉向 Kubernetes——並且有完全相同的標準；如果你知道如何在 Docker 中很好地運行你的應用程序，那麼 99% 的情況下它在 Kubernetes 中也能運行得很好。
如果您發現自己不僅對 Docker 課程的創建方式感興趣，而且對其他課程感興趣，而且從實踐的角度對課程本身感興趣，那麼
我們很高興見到您！
來源： www.habr.com