Docker Swarm实战：DevOps 2.1 工具箱

DevOps

Docker

需积分: 10 26 浏览量更新于2024-07-19 1 收藏 4.2MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"《DevOps 2.1 工具包》是一本关于使用Docker Swarm进行服务构建、测试、部署和监控的书籍，作者Viktor Farcic。" 在《DevOps 2.1 工具包》中，作者Viktor Farcic深入探讨了Docker Swarm这一关键的DevOps工具，它允许用户在Docker集群内部署、管理和扩展服务。Docker Swarm是Docker的原生容器编排系统，提供了高度可用的服务发现和负载均衡功能，使得开发者能够以声明式的方式管理容器化的应用。 DevOps是一种文化和实践，旨在通过促进开发（Development）和运维（Operations）团队之间的协作和自动化，来提高软件交付的速度和稳定性。在这个背景下，Docker Swarm成为了DevOps工具链中的重要组成部分，因为它简化了在生产环境中部署和扩展微服务架构的过程。书中详细介绍了如何构建Docker Swarm集群，包括设置节点、创建服务、配置网络以及实现服务发现。这些内容涵盖了： 1. **Docker Swarm的基础知识**：介绍Docker Swarm的基本概念，如Swarm模式、节点、服务和任务，以及它们在容器化工作流中的角色。 2. **集群初始化**：如何使用`docker swarm init`命令创建一个Docker Swarm集群，并加入其他节点以实现集群扩展。 3. **服务定义与部署**：学习编写Docker Compose文件或使用`docker service create`命令来定义和部署服务，包括指定镜像、环境变量、端口映射和副本数量。 4. **服务发现与负载均衡**：理解Docker Swarm如何自动处理服务发现和负载均衡，以及如何通过DNS名称访问服务。 5. **网络配置**：了解Docker Swarm的网络模型，包括默认的overlay网络和自定义网络的创建，以及服务间的通信。 6. **更新与滚动升级**：学习如何无中断地对服务进行更新，实现滚动升级，以确保服务的持续可用性。 7. **监控与日志管理**：探讨如何集成监控工具（如Prometheus和Grafana）和日志收集系统（如Logstash和Elasticsearch），以监控Docker Swarm集群的性能和健康状态。 8. **安全性与最佳实践**：讨论Docker Swarm的安全特性，如 TLS 加密，以及在实际操作中应遵循的最佳实践。此外，书中的案例和实战部分将帮助读者将理论知识应用于实际项目，提升对Docker Swarm的理解和使用能力。这本书适合已经熟悉Docker基础的DevOps工程师、系统管理员、开发者和架构师阅读，帮助他们更好地利用Docker Swarm实现高效且可靠的软件交付流程。

资源详情

资源推荐

Continuous Integration with

Docker Containers

It is paradoxical, yet true, to say, that the more we know, the more ignorant we become in

the absolute sense, for it is only through enlightenment that we become conscious of our

limitations. Precisely one of the most gratifying results of intellectual evolution is the

continuous opening up of new and greater prospects.

—Nikola Tesla

To fully understand the challenges and benefits that Docker Swarm brings, we need to start

from the beginning. We need to go back to a code repository and decide how are we going

to build, test, run, update, and monitor the services we're developing. Even though the

objective is to implement continuous deployment to a Swarm cluster, we need to step back

and explore Continuous Integration (CI) first. The steps we'll define for the CI process will

dictate how we proceed towards Continuous Delivery (CD), from there towards

Continuous Deployment (CDP), and, finally, how we ensure that our services are

monitored and able to self-heal. This chapter explores Continuous Integration as a

prerequisite for the more advanced processes.

A note to The DevOps 2.0 Toolkit readers

The text that follows is identical to the one published in The DevOps 2.0

Toolkit. If it is still fresh in your mind, feel free to jump to the sub-section

Defining a fully Dockerized manual Continuous Integration flow . Since I wrote

the 2.0, I discovered a few better ways to implement CI processes. I hope

you'll benefit from this chapter even if you consider yourself a veteran CI

practitioner.

To understand Continuous Deployment we should first define its predecessors, Continuous

Integration and Continuous Delivery.

Continuous Integration with Docker Containers

[ 6 ]

Integration phase of a project development tended to be one of the most painful stages of

Software Development Life Cycle (SDLC). We would spend weeks, months or even years

working in separate teams dedicated to separate applications and services. Each of those

teams would have their set of requirements and tried their best to meet them. While it

wasn't hard to periodically verify each of those applications and services in isolation, we all

dreaded the moment when team leads would decide that the time has come to integrate

them into a unique delivery. Armed with the experience from previous projects, we knew

that integration would be problematic. We knew that we would discover problems, unmet

dependencies, interfaces that do not communicate with each other correctly and that

managers will get disappointed, frustrated, and nervous. It was not uncommon to spend

weeks or even months in this phase. The worse part of all that was that a bug found during

the integration phase could mean going back and redoing days or weeks worth of work. If

someone asked me how I felt about integration back then, I'd say that it was closest I could

get to becoming permanently depressed. Those were different times. We thought that was

the right way to develop applications.

A lot changed since then. Extreme Programming (XP) and other agile methodologies

became familiar, automated testing became frequent, and Continuous Integration started to

take ground. Today we know that the way we developed software back then was wrong.

The industry moved a long way since those days.

Continuous Integration usually refers to integrating, building, and testing code within the

development environment. It requires developers to integrate code into a shared repository

often. How often is often can be interpreted in many ways and it depends on the size of the

team, the size of the project and the number of hours we dedicate to coding. In most cases, it

means that coders either push directly to the shared repository or merge their code with it.

No matter whether we're pushing or merging, those actions should, in most cases, be done

at least a couple of times a day. Getting code to the shared repository is not enough, and we

need to have a pipeline that, as a minimum, checks out the code and runs all the tests

related, directly or indirectly, to the code corresponding to the repository. The result of the

execution of the pipeline can be either red or green. Something failed, or everything was run

without any problems. In the former case, minimum action would be to notify the person

who committed the code.

The Continuous Integration pipeline should run on every commit or push. Unlike

Continuous Delivery, Continuous Integration does not have a clearly defined goal of that

pipeline. Saying that one application integrates with others does not tell us a lot about its

production readiness. We do not know how much more work is required to get to the stage

when the code can be delivered to production. All we are striving for is the knowledge that

a commit did not break any of the existing tests. Nevertheless, CI is a vast improvement

when done right. In many cases, it is a very hard practice to implement, but once everyone

is comfortable with it, the results are often very impressive.

Continuous Integration with Docker Containers

[ 7 ]

Integration tests need to be committed together with the implementation code, if not before.

To gain maximum benefits, we should write tests in Test-Driven Development (TDD)

fashion. That way, not only that tests are ready for commit together with implementation,

but we know that they are not faulty and would not pass no matter what we do. There are

many other benefits TDD brings to the table and, if you haven't already, I strongly

recommend to adopt it. You might want to consult the Test-Driven Development (

IUUQUFD

OPMPHZDPOWFSTBUJPOTDPNDBUFHPSZUFTUESJWFOEFWFMPQNFOU) section of the

Technology Conversations (

IUUQUFDIOPMPHZDPOWFSTBUJPOTDPN) blog.

Tests are not the only CI prerequisite. One of the most important rules is that when the

pipeline fails, fixing the problem has higher priority than any other task. If this action is

postponed, next executions of the pipeline will fail as well. People will start ignoring the

failure notifications and, slowly, CI process will begin losing its purpose. The sooner we fix

the problem discovered during the execution of the CI pipeline, the better we are. If

corrective action is taken immediately, knowledge about the potential cause of the problem

is still fresh (after all, it's been only a few minutes between the commit and the failure

notification) and fixing it should be trivial.

Defining a fully Dockerized manual

Continuous Integration flow

Every Continuous Integration process starts with a code that is checked out from a

repository. We'll use the GitHub repository

WGBSDJDHPEFNP (IUUQTHJUIVCDPNWGBS

JDHPEFNP) throughout the book. It contains the code of the service we'll use throughout

the book. The service is written in Go (

IUUQTHPMBOHPSH). Fear not! Even though I

consider it one of the best currently available languages, you will not be required to learn

Go. We'll use the go-demo service only as a demonstration of the processes explained

throughout the book. Even though I strongly recommend learning Go, the book does not

assume any knowledge of the language. All the examples will be programming language

agnostic.

All the commands from this chapter are available in the

DPOUJOVPVT

JOUFHSBUJPOTI

(IUUQTHJTUHJUIVCDPNWGBSDJDBFGFB

F

DBDD) Gist.

Continuous Integration with Docker Containers

[ 8 ]

A note to Windows users

Please make sure that your Git client is configured to check out the code

AS-IS. Otherwise, Windows might change carriage returns to the

Windows format.

Let's get going and check out the

HPEFNP code:

git clone https://github.com/vfarcic/go-demo.git

cd go-demo

Some of the files will be shared between the host file system and Docker Machines we'll

start creating soon. Docker Machine makes the whole directory that belongs to the current

user available inside the VM. Therefore, please make sure that the code is checked out

inside one of the user's sub-folders.

Now that we have the code checked out from the repository, we need a server that we'll use

to build and run tests. For now, we'll use Docker Machine, since it provides an easy way to

create a "Docker ready" VMs on our laptops.

The Docker Machine (

IUUQTEPDTEPDLFSDPNNBDIJOFPWFSWJFX) is a tool that lets you

install Docker Engine on virtual hosts, and manage the hosts with the

EPDLFSNBDIJOF

commands. You can use Machine to create Docker hosts on your local Mac or Windows

box, on your company network, in your data center, or on cloud providers like AWS or

DigitalOcean.

Using

EPDLFSNBDIJOF commands, you can start, inspect, stop, and restart a managed

host, upgrade the Docker client and daemon, and configure a Docker client to talk to your

host.

Machine was the only way to run Docker on Mac or Windows previous to Docker v1.12.

Starting with the beta program and Docker v1.12, Docker for Mac and Docker for Windows

are available as native apps and the better choice for this use case on newer desktops and

laptops. I encourage you to try out these new apps. The installers for Docker for Mac and

Docker for Windows include Docker Machine, along with Docker Compose.

The examples that follow assume that you have Docker Machine version

v0.9 (

IUUQTXXXEPDLFSDPNQSPEVDUTEPDLFSNBDIJOF) that includes

Docker Engine v1.13+ (

IUUQTXXXEPDLFSDPNQSPEVDUTEPDLFSFOHJO

). The installation instructions can be found in the Install Docker Machine

(

IUUQTEPDTEPDLFSDPNNBDIJOFJOTUBMMNBDIJOF) page.

Continuous Integration with Docker Containers

[ 9 ]

A note to Windows users

The recommendation is to run all the examples from Git Bash (installed

through Docker Toolbox as well as Git). That way the commands you'll see

throughout the book will be same as those that should be executed on OS

X or any Linux distribution.

A note to Linux users

Docker Machine on Linux might not be able to mount a host volume

inside VMs. The problem is related to the fact that both host and Docker

Machine OSes use

IPNF directory. Mounting IPNF from the host would

overwrite some of the required files. If you experience problems with

mounting of the host volume, please export the

7*356"-#09@4)"3&@'0-%&3 variable:

FYQPSU7*356"-#09@4)"3&@'0-%&318%18%

If machines are already created, you'll have to destroy them and create

them again.

Please note that this problem should be fixed in newer Docker Machine

versions so use this workaround only if you notice that the volume is not

mounted (files from the host are not available inside VMs).

Let's create our first server called

HPEFNP use the following command:

docker-machine create -d virtualbox go-demo

A note to Windows users

If you're using Docker for Windows instead of Docker Toolbox, you will need

to change the driver from virtualbox to Hyper-V. The problem is that

Hyper-V does not allow mounting host volumes, so it is still highly

recommended to use Docker Toolbox when working with Docker Machine.

The reason behind the choice of running Docker inside Docker Machines

instead natively on the host lies in the need to run a cluster (coming in the

next chapter). Docker Machine is the easiest way to simulate a multi-node

cluster.

The command should be self-explanatory. We specified virtualbox as the driver (or Hyper-

V if you're running Docker for Windows) and named the machine

HPEFNP:

A note to Windows users

In some cases, Git Bash might think that it is still running as BAT. If you

experience a problem with the

EPDLFSNBDIJOFFOW commands, please

export the

4)&-- variable:

FYQPSU4)&--CBTI

剩余424页未读，继续阅读

SorelCheung

粉丝: 61
资源: 120

Docker Swarm实战：DevOps 2.1 工具箱

The DevOps 2.2 Toolkit

The DevOps 2.1 Toolkit

有什么devops书籍推荐吗

学习devops的网站地址

devops pdf

Azure devops 面试题

EXIN DevOps证书有用吗

EXIN DevOps证书怎样

devops落地与转型

devops gitlab

如何学习使用devops

itu-t devops

devops 与 jupyterhub

The+Auto+DevOps+pipeline+has+been+enabled+and+will+be+used+if+no+alternative+CI+configuration+file+i

简答DevOps实施阶段

云效DevOps VS CodeArts

devops 3763.7-2021

devops 能力模型.xlsx

azure devops 使用python3脚本拉取代码

数据结构实验报告(集合)

最新资源