Docker Swarm Master 學習筆記——Create Your First Service and Scale It Locally

yidichaxiang發表於2020-12-03

視訊地址:https://www.bilibili.com/video/BV1cb411S7jw?p=6,若翻譯不準,請以視訊為準。

感謝博主的視訊資源,這是目前找到的最系統介紹 Swarm的資料了,官方文件比較適合查閱。

Alright, so wherever you're running your docker from, we can actually create a single node swarm from testing purposes, the way I can tell whether or not I can just do a docker info. And you'll notice swarm inactive, so we know this form hasn't been enabled here and again. By default, docker does not enable any of the swarm features.

好的,所以無論您在哪裡執行docker,我們實際上都可以根據測試目的建立一個單節點群集,docker info是我可以判斷是否可以執行方式。而且您會發現swarm處於非活動狀態,因此我們知道此特性尚未被啟用。預設情況下,docker不啟用任何swarm功能。

 And I can run docker swarm init. And it's for initialize. And that took about half a second, and we're done. What we have now is a single node swarm with all the features and functionality that we get out of the box. 

而且我可以執行docker swarm init。它用於初始化。大約花了半秒鐘,我們就完成了。我們現在擁有的是一個單節點叢集,具有我們開箱即用的所有功能。

Ok, so that was probably the shortest demo of this entire course, so I mean, what just happened like we type one command and magic wasn't actually any magic. It was a lot of very quick and efficient things in the go programming of docker, but essentially right out of the box, it does a bunch of PKI and security stuff, so it creates a root certificate for this warm that it will use to establish trust and sign certificates for all nodes in all managers and it will create a special certificates. Because it's a manager versus worker, and then it creates these tokens that we can actually use on other nodes to join this shoulder here.

好的,這可能是整個課程中最短的演示,所以我的意思是,就像我們鍵入一個命令而發生的事情一樣,魔術實際上並不是任何魔術。在docker的go程式設計中,這是很多非常快速和高效的事情,但是從本質上說,它開箱即用,它可以執行很多PKI和安全性工作,所以它為這個warm建立了一個根證照,它將用於為所有管理器中的所有節點建立信任和簽名證照,它將建立一個特殊的證照。因為它是manager 與worker,然後建立了這些令牌,我們可以在其他節點上實際使用它們以在這裡加入這個叢集。

Enables the Swarm API and create something called the raft consensus database, which we'll talk about later in a production part of the course, but just, you know, raft is a protocol that actually ensures consistency across multiple nodes, and it's ideal for using in the cloud where we can guarantee that anyone thing will be available for any moment in time.

啟用S​​warm API並建立一個稱為Raft共識資料庫的東西,我們將在課程的稍後部分對此進行討論,但是,您知道Raft是一種協議,實際上可以確保多個節點之間的一致性,因此非常適合在雲中使用我們可以保證任何事物在任何時刻都可用。

It creates that database on disk it stores the configuration of the swarm and then. Assuming you're on version 113 or newer, then it'll wait for any other nodes before it starts actually replicating the database over to them, and again all of this traffic that it would be doing once we create other nodes is all going to be encrypted and one of the key components of swarm that differentiated it when it first came out was that we didn't need an additional key value storage system or some database architecture to be the back end configuration management of our swarm,

它在磁碟上建立該資料庫,然後儲存群集的配置。假設您使用的是113版或更高版本,則它將等待任何其他節點,然後才開始將資料庫實際複製到它們上. 同樣,當我們建立其他節點時將要處理的所有流量都將全部加密,而swarm最初出現時對其進行區分的關鍵元件之一,就是我們不需要額外的金鑰值儲存系統或某種資料庫體系結構作為我們群的後端配置管理,

and if you've been around the industry foryears or decades, even there's this concept, typically at the config db, which is this separate database system that you usually need to make redundant that will store all the information about your orchestration and automation system, but swarm is actually built that straight into docker right into the daemon and handles it for us, so we never really need to do anything. There's no passwords to worry about. There's no special services to start up or anything like that. 

如果您從事該行業已有數十年或數十年的經驗,那麼即使是在config db上也有這個概念,通常是需要獨立的資料庫系統,該資料庫系統需要冗餘以儲存有關業務流程和自動化系統的所有資訊,但是swarm實際上是直接構建在docker中並直接進入daemon 併為我們處理的,因此我們實際上不需要做任何事情。無需擔心密碼。沒有啟動任何特殊服務或類似的東西。

 

Ok so back to the command line you'll notice here that talks about if I want to add a worker to this warm I just really need to cut and paste this onto the other servers I would add now later we're actually going to build a multi node swarm but for now we're just going to keep this at a single node and let's take a look at a couple of the commands will get out of it

好了,回到命令列,您會在這裡注意到,如果我想在此swarm中新增一個worker,我真的需要將其剪下並貼上到其他伺服器上,稍後再新增,我們實際上將進行構建一個多節點群集,但現在我們將其保留在單個節點上,讓我們看一下其中的一些命令.

 

so first thing is we can do docker node ls and in this case we're just seeing the one manager note that we've created you'll notice is marked as leader and there can only be one leader at a time amongst all managersand again, since we only got one then, obviously it's the leader and we can look at help. See what other options we have here? And really, the nodes commands used for bringing your servers in and out of the swarm or promoting them from workers to managers or demonium from managers back down the workers, 

這樣第一件事就是我們可以做docker node ls,在這種情況下,我們會看到我們建立的一個manager ,你會注意到,它被標記為leader,在所有manager 中一次只能有一個leader再說一次,因為我們只有一個,很明顯是leader,我們可以尋求help。看看我們在這裡還有其他選擇嗎?實際上,nodes命令用於將伺服器移入或移出群集,或將它們從workers提升到managers ,或從managers 升級到退役workers,

For now, let's focus on the exciting new docker service commitment. So again, service in a swarm replaces the docker run and I don't know for a fact, but I really think that this was centered around the idea that we didn't want to break existing docker run functionality, but docker run was always built from the ground up as a single host solution is a whole idea was to focus on local containers on the system that it's talking to me, whereas when we start talking about a cluster. We don't care so much about individual nodes. We don't actually probably name them. And we treat him like cattle. If you've ever heard of the pets versus cattle analogy, where they're just a number and we don't really individually go to each node and start up an individual container, we really just throw requirements at this warm in the form of services, and then it will orchestrate how it needs to lay all that out which knows they need to be, and we just know that it's got our back.

現在,讓我們專注於令人興奮的新docker service承諾。再說一次,大量docker service取代了docker run,我不知道事實原因,但是我真的認為,這是圍繞我們不想破壞現有docker run功能的想法而來的,但docker run總是從頭開始構建,作為一個單一的主機解決方案,整個想法是專注於與之對話的系統上的本地容器上,而當我們開始談論叢集時,我們不太關心單個節點。我們實際上可能沒有命名它們。我們像對待牛一樣對待他。如果您聽說過寵物與牛的類比,它們只是一個數字,而我們並沒有真正去每個節點並啟動一個單獨的容器,我們只是以service的形式向這個Swarm叢集丟擲需求,然後它將協調如何將需要知道的所有內容進行佈局,而我們只是知道它得到了我們的支援。

You specified for it, so the goal of the orchestrator is to make these numbers match whatever that takes, but this again doesn't actually show us the real container. This is really just showing us a list of our services so we can drill down a little farther. Can we do a docker service ps and then we give it the name or the id of the service and that will actually show us the tax or containers for this service, and you'll see that it's similar to the docker container ls command, but it actually has now this node component because when you're dealing with multi server scenarios we might need to know which server is actually running on you'll notice that it actually gave it a name of an increment on the service name so we went back.

若您指定了它,所以編排器的目標是使這些數字匹配所需要的任何東西,但這並沒有向我們展示真正的容器,這實際上只是向我們展示了我們的服務列表,這樣我們就可以深入得更遠一些。我們可以做一個docker service ps,然後我們給它service的名稱或id,這實際上會顯示這個服務的tax或容器,並且您會看到它類似於docker container ls命令,但是實際上它現在具有此節點元件,因為在處理多伺服器方案時,我們可能需要知道實際在哪個伺服器上執行,您會注意到它實際上給它提供了服務名稱的增量名稱,所以我們返回了。

To the docker container ls command that still works, but in this case the orchestration of swarm is actually adding some information. To the names and to the actual images that are running. More covers little differences later as well. For now, it's actually take that service and let's scale it up. For that, use the docker service update and then the name of our service or the id. In this case, I'll do the id. And I want to change an attribute about the surface, and in this case I want to change the number of replicas. And so if we do a docker service ls again, we now see three of three if we do a doctor service ps. We actually now see three tasks and you'll notice that two were just created seconds ago now if we were fast enough and if we were deployed something big enough, we could actually run the service ls and actually see it show us zero of three one of three it'll actually increment as things start up. It just so happens that alpine was already on this machine in terms of its image and it didn't take very long to start up a Ping command, so we just couldn't be that fast. 

對於docker container ls命令仍然有效的,但是在這種情況下,swarm的編排實際上是新增了一些資訊到名稱和正在執行的實際映像。更多內容也涵蓋了以後的微小差異。現在,實際上是要使用該服務,然後讓我們擴大規模。為此,請使用docker service update,然後使用我們的服務名稱或ID。在本例中,我將執行id。我想改變一個關於replicated的屬性,在這種情況下,我想改變複製的數量。因此,如果我們再做一個docker service ls,我們現在看到3/3,如果我們做一個docker service ps。我們現在實際上看到了三個任務,你會注意到,兩個任務是在幾秒鐘前建立的,如果我們足夠快,如果我們部署了足夠大的東西,我們實際上可以執行服務ls,實際上看到它向我們顯示三個中的零,當事情開始時,它實際上會增加。碰巧,就它的影像而言,alpine已經在這臺機器上了,它沒有花很長時間就啟動了一個ping命令,所以我們不能那麼快。

 

Now it's interesting about that update command, is it you can imagine the difference between the docker run command that you might use on a single dev or test server on your local machine and the production concerns of always keeping something available as much as possible, and that's one of the design goals it's warm. Command that we actually haven't used yet is the docker update command, and that was a command for the docker run containers that allowed us to update certain variables on a running container without having to kill it and restart it, and almost all of those options are related to limiting and controlling resource usage for that container because that's one of the typical things that you see when you're running a long term application is that you need to change its resources, maybe because the databases have gotten bigger and need more ram. Maybe you have a out of control process that's eating up too much CPU, and you need to limit it, but if we do a help on the docker. Service update command. You'll see that we have a lot more options because the goal of a swarm service is that is able to replace containers and update changes in the service

現在關於update命令很有趣,你能想象在本地機器上的單個dev或test伺服器上使用的docker run命令和總是保持儘可能多的可用性這是設計目標之一。我們實際上還沒有使用的命令是docker update命令,這是docker run容器的命令,它允許我們更新正在執行的容器上的某些變數,而不必殺死它並重新啟動它,幾乎所有這些選項都與限制和控制該容器的資源使用有關,因為當您執行一個長期應用程式時,您會看到一個典型的事情,那就是您需要更改它的資源,也許是因為資料庫已經變得更大,需要更多的ram。也許您有一個失控的程式,消耗了太多的cpu,您需要限制它.但是如果我們在Docker Service update命令幫助的話,您會看到我們有更多選擇,因為大量服務的目標是能夠替換容器並更新服務中的更改

Ok, so back to our docker. Container list real quick. You notice that we have these three now, and what if I went in and sort of as a rogue, did a docker container rm in a specified one of these containers? I forced it. Super say I'd be the first one. You just take it out. Alright, now I do a docker service less. You see how it shows two of three, so because I went in behind the back will swarm and I actually took away at converting container, it's gonna identify that is going to launch a new one within seconds to replace the one that went down, and so if I did a docker Service  ps on frosty you'll see that it actually shows the history of the first task here in the list as it had one failed and it started a new one 24 seconds and this is one of the responsibilities of the container orchestration system is to make sure that the services you specified are always running and if they fail, it recovers from that failure, which is way that different that docker run.

好吧,回到我們的docker 容器列表, 你注意到我們現在有這三個容器,如果我進去,作為一個盜賊,刪除其中一個指定的容器?我強迫的。我們選擇第一個,把它拿出來。好了,現在我做一個docker service ls,你看它是顯示三個中的兩個,所以因為我從後面進去,swarm如約而至,我實際上拿走了容器,它將確定在幾秒鐘內推出一個新的,以取代倒下的,所以如果我做了一個docker service ps,你會看到的,在列表中顯示第一個任務的歷史,因為它有一個失敗,它在24秒內啟動了一個新的任務,容器編排系統的職責之一是確保您指定的服務始終在執行,如果它們失敗,它從失敗中恢復過來。這是與docker run的不同

And it's a big difference. It's settling the command line, but it's a big difference because it means that there is a rollback possibilities. There's failure mitigation and a lot of intelligence built into them. So in this case, if I actually want to remove all these containers, I'd have to remove the service docker service Orem and then the frosty. Service ls see nothing if we do a docker container. Ls we see three containers? He. And there we go that shows right there the automation happening on the back end, we were able to quickly show that we deleted the service, but the orchestration system hadn't gone through all of its processes of cleaning up the service and a task behind it. His concepts should be pretty easy to understand because they're just really expanding on the docker run concepts that we've had earlier in this course, so next let's actually build a multi node swarm and start scaling our containers out. 

這是一個很大的區別。它解決了命令列問題,但是有很大的不同,因為這意味著存在回滾的可能性。有減輕故障的能力,並且內建了許多智慧。因此,在這種情況下,如果我實際上要刪除所有這些容器,則必須docker service rm刪除服務。如果我們執行docker service ls看不到任何東西。我們看到三個容器了嗎?接下來,我們展示了在後端發生的自動化,我們能夠快速地顯示我們刪除了服務,但是編排系統並沒有經歷清理服務的所有過程和它後面的任務。他的概念應該很容易理解,因為它們實際上擴充套件了我們在本課程前面已經有的docker run概念,所以接下來讓我們實際構建一個多節點群,並開始擴充套件我們的容器。

相關文章