Docker实战:Manning版

5星 · 超过95%的资源 需积分: 11 308 下载量 27 浏览量 更新于2024-07-20 1 收藏 8.84MB PDF 举报
"Manning.Docker.in.Action.2016.3.pdf 是一本由 Jeff Nickoloff 编著的 Docker 实战书籍,由 Manning 出版社发行。该书详细介绍了 Docker 的使用和实践应用,旨在帮助读者深入理解 Docker 技术。" **Docker 知识点详解** 1. **Docker 概念** Docker 是一个开源的应用容器引擎,它基于 Go 语言并遵循 Apache2.0 协议开源。Docker 允许开发者将应用程序及其依赖打包成容器,这样可以在任何运行 Docker 的平台上一致地运行,无论是在开发者本地、测试环境还是生产环境。 2. **容器与镜像** - **容器**:容器是 Docker 提供的轻量级运行时环境,它基于镜像创建,具有隔离性,每个容器都包含运行应用所需的环境,使得应用能在不干扰其他容器或主机系统的情况下运行。 - **镜像**:镜像是容器的基础,是一个只读模板,包含了运行应用所需的所有文件和配置,可以被分层构建,这样可以高效地分享和重复使用。 3. **Dockerfile** Dockerfile 是一个文本文件,其中包含了构建镜像所需的指令,如设置基础镜像、复制文件、安装依赖、定义环境变量等。通过运行 `docker build` 命令,用户可以依据 Dockerfile 创建自定义镜像。 4. **Docker Compose** Docker Compose 是一个工具,用于定义和运行多容器 Docker 应用。在 YAML 文件(docker-compose.yml)中,可以声明服务间的依赖关系、网络配置和卷挂载等,然后通过 `docker-compose up` 命令启动整个应用堆栈。 5. **Docker 网络** Docker 提供了多种网络模式,如桥接网络、主机网络、overlay 网络等,以便容器之间能进行通信。例如,桥接网络默认创建一个虚拟网络,让容器可以通过 IP 地址互相通信。 6. **Docker 注册表** Docker Registry 是用来存储和分发 Docker 镜像的仓库。Docker Hub 是一个公共的注册表,用户可以在这里查找和推送镜像。私有镜像仓库如 Harbor 可以在企业内部部署,以安全地管理组织的 Docker 镜像。 7. **Docker 安全性** Docker 提供了一些安全措施,如命名空间和控制组(cgroups)来隔离容器的资源使用,以及 SELinux 和 AppArmor 支持以增强安全性。然而,用户仍需要注意容器间的安全边界,并避免在容器中运行特权进程。 8. **Docker 与持续集成/持续部署(CI/CD)** Docker 可以与 CI/CD 工具(如 Jenkins、GitLab CI/CD 等)很好地集成,使得构建、测试和部署流程更加顺畅。通过 Docker,开发者可以确保应用在不同环境中的一致性,从而加速软件的交付过程。 9. **Docker 服务发现和服务网格** 在分布式系统中,Docker 可以与服务发现工具(如 Consul、Eureka)结合,帮助容器找到彼此。随着服务网格(如 Istio、Linkerd)的发展,Docker 成为了微服务架构中的关键组件,提供智能路由、流量管理、安全策略等功能。 10. **Docker 的扩展性** Docker 支持 Swarm 模式,允许用户创建和管理 Docker 容器集群,实现负载均衡和自动故障恢复,进一步提升了 Docker 的可扩展性和可靠性。 "Docker in Action" 这本书将详细讲解这些概念和技术,帮助读者从基础到高级全面掌握 Docker 的使用和实践。
2018-04-04 上传
Docker-in-Action.pdf In 2011, I started working at Amazon.com. In that first week my life was changed as I learned how to use their internal build, dependency modeling, and deployment tool- ing. This was the kind of automated management I had always known was possible but had never seen. I was coming from a team that would deploy quarterly and take 10 hours to do so. At Amazon I was watching rolling deployments push changes I had made earlier that day to hundreds of machines spread all over the globe. If big tech firms had an engineering advantage over the rest of the corporate landscape, this was it. Early in 2013, I wanted to work with Graphite (a metrics collection and graphing suite). One day I sat down to install the software and start integrating a personal proj- ect. At this point I had several years of experience working with open source applica- tions, but few were as dependent on such large swaths of the Python ecosystem. The installation instructions were long and murky. Over the next several hours, I discov- ered many undocumented installation steps. These were things that might have been more obvious to a person with deeper Python ecosystem knowledge. After pouring over several installation guides, reading through configuration files, and fighting an epic battle through the deepest parts of dependency hell, I threw in the towel. Those had been some of the least inspiring hours of my life. I wanted nothing to do with the project. To make matters worse, I had altered my environment in a way that was incompatible with other software that I use regularly. Reverting those changes took an embarrassingly long time. I distinctly remember sitting at my desk one day in May that year. I was between tasks when I decided to check Hacker News for new ways to grow my skillset. Articles about a technology called Docker had made the front page a few times that week. That evening I decided to check it out. I hit the site and had the software installed within a few minutes. I was running Ubuntu on my desktop at home, and Docker only had two dependencies: LXC and the Linux kernel itself. Licensed to Stephanie Bernal <nordicka.n@gmail.com> PREFACE xiv Like everyone else, I kicked the tires with a “Hello, World” example, but learned little. Next I fired up Memcached. It was downloaded and running in under a minute. Then I started WordPress, which came bundled with its own M y SQL server. I pulled a couple different Java images, and then Python images. Then my mind flashed back to that terrible day with Graphite. I popped over to the Docker Index (this was before Docker Hub) and did a quick search. The results came back, and there it was. Some random user had created a Graphite image. I pulled it down and created a new container. It was running. A simple but fully configured Graphite server was running on my machine. I had accomplished in less than a minute of download time what I had failed to do with several hours a few months earlier. Docker was able to demonstrate value with the simplest of examples and minimum effort. I was sold. Over the next week, I tried the patience of a close friend by struggling to direct our conversations toward Docker and containers. I explained how package management was nice, but enforcing file system isolation as a default solved several management problems. I rattled on about resource efficiency and provisioning latency. I repeated this conversation with several other colleagues and fumbled through the container story. Everyone had the same set of tired questions, “Oh, it’s like virtualization?” and “Why do I need this if I have virtual machines?” The more questions people asked, the more I wanted to know. Based on the popularity of the project, this is a story shared by many. I began including sessions about Docker when I spoke publicly. In 2013 and 2014, only a few people had heard of Docker, and even fewer had actually tried the software. For the most part, the crowds consisted of a few skeptical system administrator types and a substantial number of excited developers. People reacted in a multitude of ways. Some were pure rejectionists who clearly preferred the status quo. Others could see problems that they experienced daily solved in a matter of moments. Those peo- ple reacted with an excitement similar to mine. In the summer of 2014, an associate publisher with Manning called me to talk about Docker. After a bit more than an hour on the phone he asked me if there was enough content there for a book. I suggested that there was enough for a few books. He asked me if I was interested in writing it, and I became more excited than I had been for some time. That fall I left Amazon.com and started work on Docker in Action. Today, I'm sitting in front of the finished manuscript. My goal in writing this book was to create something that would help people of mixed backgrounds get up to speed on Docker as quickly as possible, but in such a way that they understand the underlying mechanisms. The hope is that with that knowledge, readers can under- stand how Docker has been applied to certain problems, and how they might apply it in their own use-cases.