尧图网页设计 
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 90 天 DevOps 学习计划#90DaysOfDevOps波兰语版系列的第二天内容承接 第 1 天「DevOps 引言」聚焦于DevOps 工程师的具体职责。读完本文你将理解软件交付中 Development开发与 Operations运维两大阵营的分工理清 DevOps 作为二者之间桥梁的定位并掌握一位 DevOps 工程师在服务器部署、操作系统、网络、容器化与持续发布等环节中真正需要承担的能力范围——以及哪些知识只需要够用而非精通。软件交付的两大支柱Development 与 Operations在第一天我们建立了基础认知DevOps 是一种文化与实践集合其核心目标是缩短从产品构思到交付给终端用户的时间。今天我们要深入一个关键概念任何应用的诞生都包含两个相互独立又必须协作的领域。Development开发软件开发者负责编写应用程序并进行测试。这里涉及的是一行行的代码、功能特性与 Bug 修复。Operations运维应用被部署到服务器上并持续维护运行。这里涉及的是环境、基础设施与可用性保障。从 第 1 天文档 中我们可以回顾到DevOps 的思维方式强调打破开发、运维与 QA 之间的壁垒silo。而今天的内容进一步指出DevOps 正是连接这两个世界的桥梁。要真正理解 DevOps 工程师的职责就必须理解这两个世界各自的工具、流程以及它们如何衔接在一起。而这一切的起点是应用本身——在后续 90 天的学习中你会反复看到谈到 DevOps 时几乎所有话题最终都会落到应用上。开发者世界应用从何而来开发者使用多种技术栈创建应用这可能涉及多种编程语言各类构建工具build tools不同的代码仓库code repositories。作为 DevOps 工程师你通常不会亲自编写应用代码但这不代表你可以对开发一无所知。恰恰相反深入理解开发者如何工作、他们使用哪些系统、工具与流程是 DevOps 工程师成功的关键。在高层面你需要知道应用如何配置以连接其所需的服务与数据服务——即应用与数据库、消息队列、外部 API 等依赖之间的通信方式这种通信应如何被测试——如何验证应用与周边服务的连通性与正确性。这两个知识点虽然只是了解层面的要求却是你与开发者顺畅对话、并为后续部署负责的基础。运维世界应用运行在哪里应用必须被部署到某个地方。为简化理解我们假设它是一台服务器——无论它在哪里这台服务器必须对客户或终端用户可达。服务器的运行位置有多种选择部署形态说明On-Premises本地机房自有物理服务器或虚拟化平台完全自主控制Public Cloud公有云租用云厂商提供的计算资源按需扩展Serverless无服务器无需管理服务器的执行模型本文档明确表示该项目不覆盖此形态但指出这是越来越多的企业选择的方向创建并配置这些服务器、使其准备好承载应用很可能就是 DevOps 工程师的职责范围。这正是本仓库中大量实操内容存在的意义2022/Days/IaC 目录下的 Terraform 示例Hello-world、Virtualbox、Docker、Kubernetes等场景展示了如何用代码描述并创建基础设施云平台部分2022/Days/Cloud围绕 Azure 的虚拟网络、流量管理、存储与无服务器模型展开。操作系统基本盘是 Linux这些服务器上运行着操作系统通常就是 Linux。正因如此整个学习计划专门安排了一整周/一整节来覆盖 Linux 基础知识参见 第 1420 天 的 Linux 专题。仓库中配套的实操脚本可以佐证这一点例如 create-user.sh 演示了通过 bash 脚本管理 Linux 用户#! /usr/bin/bash if [ -z ${1} ] then echo What is your intended username? read username echo What is your password read password #A user can be passed in as a command line argument echo $username user account being created. #A user is created with the name of command line argument sudo useradd -m $username #A password can be parsed in as a command line argument. sudo chpasswd $username:$password sleep 2 echo If you want to delete the user then pass del and username in command line argument. e.g: ./create-user.sh del username else sudo userdel -rf ${2} sleep 2 echo ${2} user account successfully deleted. exit 0 fi这段脚本直观展示了 DevOps 工程师日常会遇到的系统管理任务创建用户useradd -m、设置密码chpasswd、删除用户userdel -rf——这些是把服务器准备好给应用运行这一职责的具体体现。网络让服务器彼此对话服务器很可能需要与网络或环境中的其他服务通信因此 DevOps 工程师也需要具备网络及其配置层面的知识。文档明确提到的知识点包括DNS域名解析DHCP动态主机配置Load Balancing负载均衡。仓库的 2022/Days/Networking 目录提供了大量配套证据paramiko_show.py、netmiko_con_multi.py、netmiko_sendchange.py等脚本展示了用 PythonParamiko / Netmiko自动化配置网络设备的真实做法而R1、SW1SW4等设备配置与backup.py则对应了网络设备的配置与备份场景。网络主题的完整讲解位于 第 2127 天 的专项章节。Jack of all trades, Master of none知识边界的艺术在讲完开发与运维两个世界后文档给出了一条非常重要的职业定位建议即Jack of all trades, Master of none万事通无一精你不需要成为网络或基础设施专家只需要具备把东西跑起来并让它们互相通信的基础知识你不需要成为开发者只需要像掌握一门编程语言的基础知识那样理解开发侧的概念但如果你以某个领域的专家身份进入 DevOps那将是非常好的起点可以在此基础上向其他领域延伸。同时需要明确你大概率不会接管服务器或应用的日常运维管理工作。DevOps 工程师的日常重心是让交付流程运转起来而不是像系统管理员那样逐日维护每一台机器。容器化90 天计划的重点方向前文一直在谈服务器但现实是你的应用更可能是以容器container的形式开发和运行的。容器大多仍然运行在服务器上但理解它需要额外掌握几个层次的概念虚拟化Virtualisation——虚拟机层面的资源隔离云端的 Infrastructure as a ServiceIaaS——按需获取计算资源容器化Containerisation——以镜像与容器为单位打包、分发和运行应用。在这 90 天中重点会更多倾斜向容器。仓库提供了直接的示例佐证。Dockerfile 展示了容器镜像的构建方式——基于 Ubuntu 基础镜像、创建非 root 用户并以该用户运行应用# Use the official Ubuntu 18.04 as base FROM ubuntu:18.04 # Install nginx and curl RUN apt-get update apt-get upgrade -y #RUN apt-get install -y nginx curl #RUN rm -rf /var/lib/apt/lists/* RUN groupadd -g 1000 basicuser useradd -r -u 1000 -g basicuser basicuser USER basicuser注意其中的安全实践创建专用用户groupadd/useradd并用USER basicuser切换避免以 root 运行容器——这正是容器化时代 DevOps 工程师需要具备的常识。容器专题的完整内容位于 第 4248 天而 2022/Days/Kubernetes 下的nginx-stateless-demo.yaml、statefulset.yaml、pacman-ingress.yaml等示例则为后续的容器编排学习埋下了伏笔。高层总结DevOps 工程师到底做什么将两个世界放在一起看全景是这样的一边是开发者为应用创造新功能、新特性同时修复 Bug另一边是环境与基础设施配置并管理服务器使应用能运行起来并与所有必需的服务通信。于是核心问题浮现我们如何把这些功能与修复交付到产品中并让终端用户真正可用核心任务持续、自动化、高效的发布如何发布新版本应用正是 DevOps 工程师的主要任务之一。关键不在于搞定一次而在于持续地continuously进行发布而非一次性手工操作自动化automated减少人工干预与人为失误高效efficient让交付链路足够快必须包含测试testing——测试要嵌入整个流程而不是事后补做。这与仓库后续章节一脉相承持续集成/持续交付CI/CD专题第 7076 天配套的 Jenkins 部署配置jenkins-namespace.yml、jenkins-sa.yml、jenkins-values.yml、jenkins-volume.yml与Pipeline/目录正是自动化、持续地交付应用这一职责的落地工具而配置管理专题第 6369 天下的 Ansible 示例ansible-scenario1ansible-scenario7、simple_play.yml则对应了配置并管理服务器使其可运行应用的职责。延伸学习资源本文档作者始终欢迎社区补充更多学习资源以下是其推荐用于巩固什么是 DevOps的公开资料均为视频或官方文档类入门内容建议全部观看What is DevOps? — TechWorld with NanaYouTubeWhat is DevOps? — GitHub YouTubeWhat is DevOps? — IBM YouTubeWhat is DevOps? — AWS 官方文档What is DevOps? — Microsoft 官方文档如果读到这里你已经确定了方向那么请继续进入 第 3 天DevOps 生命周期——以应用为中心。明天我们将更深入地审视 DevOps 的其他领域然后进入对工具、流程及其收益的深层剖析。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第 2 天DevOps 工程师的职责——连接开发与运维的桥梁90DaysOfDevOps 第 2 天DevOps 工程师的职责——连接开发与运维的桥梁 导读 本文是《90DaysOfDevOps》90 天学习挑战的第文档/教程90DaysOfDevOps 第 2 天DevOps 工程师的职责全景——连接开发与运维的桥梁90DaysOfDevOps 第 2 天DevOps 工程师的职责全景——连接开发与运维的桥梁 本篇是 90DaysOfDevOps https://link文档/教程Grafast 基准测试工具详解内置 bench 的性能回归监控原理与实战Grafast 基准测试工具详解内置 bench 的性能回归监控原理与实战 本指南以 grafast/bench https://link.gitcode.c文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 第 2 天：DevOps 工程师的职责——从开发与运维双视角理解 DevOps 的角色边界
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 90 天 DevOps 学习计划#90DaysOfDevOps波兰语版系列的第二天内容承接 第 1 天「DevOps 引言」聚焦于DevOps 工程师的具体职责。读完本文你将理解软件交付中 Development开发与 Operations运维两大阵营的分工理清 DevOps 作为二者之间桥梁的定位并掌握一位 DevOps 工程师在服务器部署、操作系统、网络、容器化与持续发布等环节中真正需要承担的能力范围——以及哪些知识只需要够用而非精通。软件交付的两大支柱Development 与 Operations在第一天我们建立了基础认知DevOps 是一种文化与实践集合其核心目标是缩短从产品构思到交付给终端用户的时间。今天我们要深入一个关键概念任何应用的诞生都包含两个相互独立又必须协作的领域。Development开发软件开发者负责编写应用程序并进行测试。这里涉及的是一行行的代码、功能特性与 Bug 修复。Operations运维应用被部署到服务器上并持续维护运行。这里涉及的是环境、基础设施与可用性保障。从 第 1 天文档 中我们可以回顾到DevOps 的思维方式强调打破开发、运维与 QA 之间的壁垒silo。而今天的内容进一步指出DevOps 正是连接这两个世界的桥梁。要真正理解 DevOps 工程师的职责就必须理解这两个世界各自的工具、流程以及它们如何衔接在一起。而这一切的起点是应用本身——在后续 90 天的学习中你会反复看到谈到 DevOps 时几乎所有话题最终都会落到应用上。开发者世界应用从何而来开发者使用多种技术栈创建应用这可能涉及多种编程语言各类构建工具build tools不同的代码仓库code repositories。作为 DevOps 工程师你通常不会亲自编写应用代码但这不代表你可以对开发一无所知。恰恰相反深入理解开发者如何工作、他们使用哪些系统、工具与流程是 DevOps 工程师成功的关键。在高层面你需要知道应用如何配置以连接其所需的服务与数据服务——即应用与数据库、消息队列、外部 API 等依赖之间的通信方式这种通信应如何被测试——如何验证应用与周边服务的连通性与正确性。这两个知识点虽然只是了解层面的要求却是你与开发者顺畅对话、并为后续部署负责的基础。运维世界应用运行在哪里应用必须被部署到某个地方。为简化理解我们假设它是一台服务器——无论它在哪里这台服务器必须对客户或终端用户可达。服务器的运行位置有多种选择部署形态说明On-Premises本地机房自有物理服务器或虚拟化平台完全自主控制Public Cloud公有云租用云厂商提供的计算资源按需扩展Serverless无服务器无需管理服务器的执行模型本文档明确表示该项目不覆盖此形态但指出这是越来越多的企业选择的方向创建并配置这些服务器、使其准备好承载应用很可能就是 DevOps 工程师的职责范围。这正是本仓库中大量实操内容存在的意义2022/Days/IaC 目录下的 Terraform 示例Hello-world、Virtualbox、Docker、Kubernetes等场景展示了如何用代码描述并创建基础设施云平台部分2022/Days/Cloud围绕 Azure 的虚拟网络、流量管理、存储与无服务器模型展开。操作系统基本盘是 Linux这些服务器上运行着操作系统通常就是 Linux。正因如此整个学习计划专门安排了一整周/一整节来覆盖 Linux 基础知识参见 第 1420 天 的 Linux 专题。仓库中配套的实操脚本可以佐证这一点例如 create-user.sh 演示了通过 bash 脚本管理 Linux 用户#! /usr/bin/bash if [ -z ${1} ] then echo What is your intended username? read username echo What is your password read password #A user can be passed in as a command line argument echo $username user account being created. #A user is created with the name of command line argument sudo useradd -m $username #A password can be parsed in as a command line argument. sudo chpasswd $username:$password sleep 2 echo If you want to delete the user then pass del and username in command line argument. e.g: ./create-user.sh del username else sudo userdel -rf ${2} sleep 2 echo ${2} user account successfully deleted. exit 0 fi这段脚本直观展示了 DevOps 工程师日常会遇到的系统管理任务创建用户useradd -m、设置密码chpasswd、删除用户userdel -rf——这些是把服务器准备好给应用运行这一职责的具体体现。网络让服务器彼此对话服务器很可能需要与网络或环境中的其他服务通信因此 DevOps 工程师也需要具备网络及其配置层面的知识。文档明确提到的知识点包括DNS域名解析DHCP动态主机配置Load Balancing负载均衡。仓库的 2022/Days/Networking 目录提供了大量配套证据paramiko_show.py、netmiko_con_multi.py、netmiko_sendchange.py等脚本展示了用 PythonParamiko / Netmiko自动化配置网络设备的真实做法而R1、SW1SW4等设备配置与backup.py则对应了网络设备的配置与备份场景。网络主题的完整讲解位于 第 2127 天 的专项章节。Jack of all trades, Master of none知识边界的艺术在讲完开发与运维两个世界后文档给出了一条非常重要的职业定位建议即Jack of all trades, Master of none万事通无一精你不需要成为网络或基础设施专家只需要具备把东西跑起来并让它们互相通信的基础知识你不需要成为开发者只需要像掌握一门编程语言的基础知识那样理解开发侧的概念但如果你以某个领域的专家身份进入 DevOps那将是非常好的起点可以在此基础上向其他领域延伸。同时需要明确你大概率不会接管服务器或应用的日常运维管理工作。DevOps 工程师的日常重心是让交付流程运转起来而不是像系统管理员那样逐日维护每一台机器。容器化90 天计划的重点方向前文一直在谈服务器但现实是你的应用更可能是以容器container的形式开发和运行的。容器大多仍然运行在服务器上但理解它需要额外掌握几个层次的概念虚拟化Virtualisation——虚拟机层面的资源隔离云端的 Infrastructure as a ServiceIaaS——按需获取计算资源容器化Containerisation——以镜像与容器为单位打包、分发和运行应用。在这 90 天中重点会更多倾斜向容器。仓库提供了直接的示例佐证。Dockerfile 展示了容器镜像的构建方式——基于 Ubuntu 基础镜像、创建非 root 用户并以该用户运行应用# Use the official Ubuntu 18.04 as base FROM ubuntu:18.04 # Install nginx and curl RUN apt-get update apt-get upgrade -y #RUN apt-get install -y nginx curl #RUN rm -rf /var/lib/apt/lists/* RUN groupadd -g 1000 basicuser useradd -r -u 1000 -g basicuser basicuser USER basicuser注意其中的安全实践创建专用用户groupadd/useradd并用USER basicuser切换避免以 root 运行容器——这正是容器化时代 DevOps 工程师需要具备的常识。容器专题的完整内容位于 第 4248 天而 2022/Days/Kubernetes 下的nginx-stateless-demo.yaml、statefulset.yaml、pacman-ingress.yaml等示例则为后续的容器编排学习埋下了伏笔。高层总结DevOps 工程师到底做什么将两个世界放在一起看全景是这样的一边是开发者为应用创造新功能、新特性同时修复 Bug另一边是环境与基础设施配置并管理服务器使应用能运行起来并与所有必需的服务通信。于是核心问题浮现我们如何把这些功能与修复交付到产品中并让终端用户真正可用核心任务持续、自动化、高效的发布如何发布新版本应用正是 DevOps 工程师的主要任务之一。关键不在于搞定一次而在于持续地continuously进行发布而非一次性手工操作自动化automated减少人工干预与人为失误高效efficient让交付链路足够快必须包含测试testing——测试要嵌入整个流程而不是事后补做。这与仓库后续章节一脉相承持续集成/持续交付CI/CD专题第 7076 天配套的 Jenkins 部署配置jenkins-namespace.yml、jenkins-sa.yml、jenkins-values.yml、jenkins-volume.yml与Pipeline/目录正是自动化、持续地交付应用这一职责的落地工具而配置管理专题第 6369 天下的 Ansible 示例ansible-scenario1ansible-scenario7、simple_play.yml则对应了配置并管理服务器使其可运行应用的职责。延伸学习资源本文档作者始终欢迎社区补充更多学习资源以下是其推荐用于巩固什么是 DevOps的公开资料均为视频或官方文档类入门内容建议全部观看What is DevOps? — TechWorld with NanaYouTubeWhat is DevOps? — GitHub YouTubeWhat is DevOps? — IBM YouTubeWhat is DevOps? — AWS 官方文档What is DevOps? — Microsoft 官方文档如果读到这里你已经确定了方向那么请继续进入 第 3 天DevOps 生命周期——以应用为中心。明天我们将更深入地审视 DevOps 的其他领域然后进入对工具、流程及其收益的深层剖析。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第 2 天DevOps 工程师的职责——连接开发与运维的桥梁90DaysOfDevOps 第 2 天DevOps 工程师的职责——连接开发与运维的桥梁 导读 本文是《90DaysOfDevOps》90 天学习挑战的第文档/教程90DaysOfDevOps 第 2 天DevOps 工程师的职责全景——连接开发与运维的桥梁90DaysOfDevOps 第 2 天DevOps 工程师的职责全景——连接开发与运维的桥梁 本篇是 90DaysOfDevOps https://link文档/教程Grafast 基准测试工具详解内置 bench 的性能回归监控原理与实战Grafast 基准测试工具详解内置 bench 的性能回归监控原理与实战 本指南以 grafast/bench https://link.gitcode.c文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考