python DevOps

在云原生中，python扮演的角色是什么？

在云原生环境中，Python 作为一种高级编程语言，在多个方面扮演着重要角色。云原生是指利用云计算的各种优势（如弹性、可扩展性和自动化），构建和运行应用程序的方法和技术集合。在这样的环境中，Python 的特点和优势如下：

1. 微服务架构：云原生应用通常基于微服务架构，这意味着应用被拆分为一系列小的、独立的服务，每个服务执行应用的特定功能。Python 由于其简洁性、易读性和广泛的库支持，非常适合快速开发和部署微服务。

2. 容器和编排：在云原生环境中，容器（如Docker）和容器编排技术（如Kubernetes）是核心组件。Python 应用可以容易地容器化，并在任何支持容器技术的环境中部署。此外，还有多个用于管理容器化应用程序生命周期的 Python 库和工具。

3. 自动化和API：Python 是自动化的一个非常强大的工具，这在云原生环境中尤为重要。利用 Python，可以编写脚本和工具来自动化部署流程、监控、数据收集等。同时，Python 的广泛的库和框架可以用于快速开发 RESTful API，这对于微服务之间的通信至关重要。

4. 数据分析和机器学习：云原生应用程序常常需要处理大量数据以及进行实时分析。Python 在数据科学、分析和机器学习领域非常强大，拥有如 NumPy、Pandas、SciPy、TensorFlow 和 PyTorch 等库，使其能够高效地处理数据操作和计算。

5. DevOps 工具链集成：在云原生和 DevOps 环境中，持续集成和持续部署（CI/CD）是常见的实践。Python 可以集成到 DevOps 工具链中，提供脚本支持，用于构建、测试、部署和监控应用程序。

6. 云服务交互：大多数云提供商（如 AWS、Google Cloud Platform、Microsoft Azure 等）都提供了 Python SDK，使得开发人员能够直接与云服务进行交互，更轻松地集成云功能和服务。

总之，Python 由于其灵活性、易用性以及丰富的库生态系统，在云原生开发的许多方面都扮演着关键角色。它帮助团队快速迭代，适应云原生环境中不断变化的需求和挑战。

1、用python的 subprocess就能写出ping 255个ip哪个不通。多进程就能快很多，用fork

2、子进程在循环中不写exit(),会发生再生成子进程，核心就是子进程下次循环就少一次，生出孙进程，循环少两次。。。直到结束

windows是没有os.fork的，多进程不行，但支持多线程

import os
import time

def main():
    for i in range(5):  # 仅仅为了示例，我们尝试创建5个子进程
        pid = os.fork()
        if pid == 0:  # 判断当前进程是否是子进程
            # 这里是子进程
            print(f"子进程: {os.getpid()}")
            # 如果没有exit，子进程将继续执行循环
            # ... 子进程需要执行的代码 ...

            # 非常重要: 子进程完成工作后应该退出
            # os._exit(0)
        else:
            # 这里是父进程
            print(f"父进程: {os.getpid()}, 创建了子进程: {pid}")
        
        time.sleep(1)  # 让循环稍微慢一点，更容易观察

if __name__ == "__main__":
    main()

3 python和go的区别

4 进程和线程，协程概念

5 爬虫 urllib

可以读取网页内容，保存成文件，图片，视频，声音都可以
有些大文件，每次读取一部分

urllib是比较底层的，可以用上层wget这个工具， python中 import wget

可以把网站的所有图片都下载到本地一个文件夹中

面对障碍

1、可以设置一些headers信息（User-Agent）,模拟成浏览器去访问这些网站
2、url 里面有中文，阿斯码解不了，浏览器人家是自己给转码了，代码中要加上 request.quote(‘中文’)

6 paramiko

pip install paramiko
代码中变成ssh客户端，用于 多线程 执行远程命令

7 邮件

发送邮件,收邮件
plain代表纯文本，就像vi编辑的都是文本，富文本就是又有图片，又有链接
下面是给自己主机上面的其他用户发邮件。还可以向互联网上发邮件

SMTP: 简单邮件传输协议，用的TCP 端口25。python 中用 smtplib

8 JSON

跨语言通信，python有元组，列表list，没数组，发送给另一个语言有数组的就会用到 json, 先转成json字符串作为中介

9 request – HTTP库，比urillib3更简单

GET PUT POST DELETE

10 Ansible

它是python编写的，可以 pip install ansible==2.7.2
ssh-keyscan就能把密钥扫描保存下来就省的每台注意ssh后输入yes
比如 ssh-keyscan host1 host2 host3 >> ~/.ssh/known_hosts

playbook
模块名字，目标hosts是谁？tasks干什么？

1. 能每台机器yum安装，可以更新到最新的版本或者已经存在
2. 能设置服务起来并且enable

Ansible API

下面两点 interview 问遇到的问题，这个就可以用上
3. 就是用 python 控制 ansible Adhoc和 Playbook
ssh控制其他主机的时候提供的用户不是root，就需要提权操作
become = yes
become_method= sudo
become_user= root
become_ask_pass = no 不用输入密码，需要设置这个需要提权的用户 NOPASSWD: ALL
4. 不希望 playbook 中明文出现密码的时候，可以用vault_pass加密,
ansible-vault encrypt /tmp/passwd 输入加密密码
cat /tmp/passwd 就是加密文件了
解密用 ansible-valut decrypt /tmp/passwd
5. 运行playbook 就是方法里传入 hosts文件和 yaml 文件

Ansible 模块开发

灰色注释就是用法，不过首先要配置环境变量=你设计的这些模块的代码的目录
把注释中的“用法”，删掉，不要有中文，否则编码错误

下面是从url文件下载到本地，远程主机，就是执行代码那台也要安装wget

11 Git 版本控制系统

能回溯到以前的版本，多人协作

暂存区就是后悔药

01 git安装后，配置用户信息

–global代表全局生效
执行 git config --global core.editor vim 后，当 Git 需要你编辑文本的时候，它会自动打开 Vim 编辑器让你进行编辑。这是一种个性化你的工作环境的方式，确保 Git 在各种需要输入文本的情况下使用你最喜欢或最习惯的编辑器。

02 基础应用

1. 创建仓库
   
   
   .git就是版本库
   也可以git clone过来项目，上面就是初始化仓库的三个方法
   
   git add就是放到暂存区，也就是开始跟踪文件了，commit就是放到版本库里了
   git add .把所有的文件都跟踪
   不想跟踪某些文件，用 .gitignore来控制
   ls .git会看到 index这个文件，这个就是暂存区，commit之后才会进入到版本库 .git
   干净的工作区：就是无文件要提交
   git add 后，可以 git reset HEAD … 撤出暂存区。
   git commit -m “这次提交的注释”
   

03 git reset 和 git rm 是 Git 中用于处理文件更改的两个不同命令，它们的用途和行为有重要差异。以下是每个命令的功能及其常见用例。

1. git reset：就是从暂存区撤出，之前修改的内容还在，就是需要再次git add

• 用途：git reset 主要用于取消已经暂存的更改。你可以用它来撤销对暂存区的修改，例如错误地添加了一些文件到暂存区（stage）时。

• 行为：当你使用 git add 将文件添加到暂存区后，如果你决定不想提交某些文件，可以使用 git reset HEAD 来将它们从暂存区移回工作区。

• 示例：假设你修改了两个文件 file1.txt 和 file2.txt 并用 git add 将它们添加到暂存区。如果你决定只提交 file1.txt，可以使用 git reset HEAD file2.txt 将 file2.txt 从暂存区移除。

  git add file1.txt file2.txt # 将文件添加到暂存区
  git reset HEAD file2.txt    # 将 file2.txt 从暂存区移除
  

  这样，file2.txt 的更改不会出现在接下来的提交中，但文件的更改仍会保留在你的工作目录中。

2. git rm：

• 用途：git rm 用于从工作目录和暂存区中删除文件，它告诉 Git 你希望在接下来的提交中删除这些文件，同时也将文件从你的实际工作目录中移除。

• 行为：git rm 不仅会将文件从暂存区中移除，还会从物理磁盘中删除文件。

• 示例：如果你不再需要 file3.txt，你可以用 git rm file3.txt 来删除它。

  git rm file3.txt            # 删除文件并从暂存区移除
  git commit -m "Remove file3.txt" # 提交这次删除操作
  

  这会在你的下一次提交中删除 file3.txt，并且 file3.txt 也不再出现在你的文件系统中。

总的来说，git reset 更多的是关于取消暂存的更改，而 git rm 是关于完全删除文件（从工作目录和版本历史中）。使用这些命令时需要谨慎，以确保不会误删工作或者将不想提交的更改添加到版本历史中。

04 git log 查看提交历史

05 git check out 慎用，因为你的修改不在，直接回到解放前某个提交版本

在 Git 中，git checkout 命令用于切换分支或恢复工作目录文件。它是一个多功能命令，主要用于以下几种情况：

1. 切换分支：如果你想要切换到一个不同的分支，你可以使用 git checkout 加上你想要切换到的分支的名字。

   示例：

   git checkout develop
   

   这个命令会将你当前的工作分支切换到名为 develop 的分支。如果这个分支不存在，Git 会给出一个错误提示。

2. 创建新分支并切换到该分支：如果你想要创建一个新分支并立即切换到这个分支，你可以添加 -b 参数来实现。

   示例：

   git checkout -b new-feature
   

   这个命令会创建一个名为 new-feature 的新分支，并将当前分支切换到这个新分支。

3. 恢复文件：如果你对一些文件进行了修改但还未提交，而现在你想放弃这些修改，返回到最后一次提交的状态，你可以使用 git checkout。

   示例：

   git checkout -- file1.txt
   

   这条命令会放弃对 file1.txt 文件的所有修改，使其返回到最后一次提交的状态。请注意，这会删除自上次提交以来对该文件的所有修改，所以在使用此命令前要确保不需要这些修改。

4. 检出特定的提交：如果你想查看项目历史中的特定提交或标签，可以使用 git checkout 加上提交的哈希值或标签名。

   示例：

   git checkout 7a052cf
   

   这会更新工作目录中的所有文件，使其反映在哈希值为 7a052cf 的提交时的状态。在这种状态下，你处于一个“DETACHED HEAD”状态，意味着不在任何分支上，这个状态下的任何更改都不会记录到项目历史中，除非你创建一个新分支。

请注意，在 Git 的新版本中，一些 git checkout 的功能已经被更专一的命令所取代，例如用于切换分支的 git switch 命令和用于恢复文件的 git restore 命令。这些新命令的目的是使 Git 的操作更加直观和用户友好。不过，git checkout 命令在很多情况下仍然可用，且被广泛理解和采纳。

06 git 分支管理

git如果两人都同时修改了一个项目的代码，都提交了会发生什么？git是怎样保证多人协作开发一个项目的呢？

在使用Git进行多人协作开发时，多个开发者同时对代码进行更改并提交是常见的情况。当两个开发者都修改了同一项目的代码并尝试提交时，Git的处理方式取决于具体的操作和情况。以下是通常会发生的情况和Git如何管理这种多人协作的方式。

1. 分支和合并（Branching and Merging）：

   • Git鼓励使用分支来进行功能开发。每个开发者可以在自己的分支上工作，完成后再将分支合并回主分支（如main或master）。这样可以减少冲突的可能性。

2. 拉取和合并代码（Pull and Merge）：

   • 当一个开发者（比如说开发者A）想要提交（push）代码到远程仓库时，如果在此期间另一个开发者（开发者B）已经提交了更新，那么开发者A的提交可能会被拒绝，因为他的本地版本已经落后于远程仓库的版本。
   • 在这种情况下，开发者A需要先执行git pull（这通常会自动合并远程的更改，或者如果有冲突则需要手动解决）或者git fetch然后git merge（如果希望分步操作）来整合开发者B的更改。
   • 如果两个开发者更改了同一文件的同一部分，Git无法自动解决合并冲突，此时开发者A需要手动解决这些冲突。

3. 解决合并冲突（Resolving Merge Conflicts）：

   • 在合并时，如果两个开发者修改了同一文件的同一部分，Git会标记出冲突并要求手动解决。开发者需要选择保留哪些更改，或者创建新的内容来替换冲突部分。
   • 解决冲突后，开发者需要进行提交，以完成合并过程。

4. 代码审查（Code Reviews）：

   • 在多人团队中，通常会通过Pull Requests（PR）或Merge Requests（MR）来引入更改。这为团队提供了一个审查代码、提出修改建议并讨论更改的平台，从而可以在代码合并到主分支之前确保代码质量。

5. 使用分布式工作流（Distributed Workflows）：

   • Git是一个分布式版本控制系统，每个开发者都有项目的完整本地副本。这允许开发者离线工作，并在准备好之后推送更改，系统会自动合并冲突或提示需要手动解决。

通过以上方法，Git可以高效地管理多人对代码库的更改，确保版本的一致性和项目的顺利进行。同时，开发者也需要遵循一定的最佳实践（例如常规同步远程更改、合理使用分支等），以保证多人协作的流畅。

git fetch然后git merge和git pull的区别是什么？git fetch然后git merge这两步分别做了什么？

git fetch、git merge 和 git pull 都是 Git 中用于更新本地代码库的命令。尽管它们都是为了从远程仓库获取最新更改并将这些更改应用到本地仓库，但它们的工作方式有所不同。下面是每个命令的具体作用和这些命令之间的区别。

1. git fetch：

• 当你执行 git fetch 时，Git 会连接到远程仓库，检查你当前没有的所有更改或更新（比如其他人提交的新分支或提交等），并将这些信息拉取到你的本地仓库。
• 重要的是，git fetch 只是将这些更新下载到本地仓库，并不会自动合并到你当前的工作分支。这些更改保留在所谓的“远程分支”中。

2. git merge：

• 在执行 git fetch 之后，如果你想要将这些更改应用到你的当前分支（比如 main），你需要执行 git merge（例如，git merge origin/main）。
• git merge 会将指定分支（在本例中是远程分支 origin/main）的更改合并到当前活动分支。如果存在冲突，你需要手动解决这些冲突。

3. git pull：

• git pull 是一个方便的命令，实际上它是 git fetch 和 git merge 的组合。当你执行 git pull 时，Git 会从远程仓库拉取最新的更改（就像 git fetch 那样）并立即尝试将这些更改合并到你的当前分支（就像 git merge 那样）。
• 这意味着，如果你直接使用 git pull，你可能需要立即处理合并冲突。而使用 git fetch 后再使用 git merge 可以让你有更多的控制：你可以先查看更新，然后再决定如何合并。

总结一下，git fetch 然后 git merge 提供了更多的控制，允许你在合并之前检查更改。这对于复杂的项目或需要审慎合并的场景特别有用。而 git pull 是一个更快捷的方式，适用于你信任拉取的更改并希望直接合并它们的情况。在团队协作中，了解何时使用哪种方法是非常重要的，以确保代码库的整洁和项目的稳定性。

Pull Requests（PR）或Merge Requests（MR）是什么？请举例说明

Pull Requests（PR）和 Merge Requests（MR）是版本控制协作中的关键概念，常用于多人开发的项目中。这些请求允许开发者通知团队成员他们对代码所作的更改，请求他人审查这些更改，并将它们合并到主分支。这两个术语在功能上非常相似，但它们是由不同的Git仓库托管服务使用的；GitHub使用“Pull Requests”，而GitLab使用“Merge Requests”。

以下是Pull Request或Merge Request的一般流程，以及它们是如何用于团队协作的：

1. 创建分支：
   开发者从主代码库（通常是main或master分支）创建一个新分支，在这个新分支上进行开发。这确保了主分支的稳定性，即使是在多人同时工作的情况下。

2. 提交更改：
   开发者在新分支上进行更改，这可能包括修复错误、添加新功能等。更改完成后，开发者会将这些更改提交到新分支，并将该分支推送到远程仓库（如GitHub或GitLab）。

3. 发起Pull Request/Merge Request：
   开发者在远程仓库上创建一个PR或MR。这实际上是一种请求，要求其他团队成员审查代码、提出反馈或建议，并最终将这个分支的更改合并到主分支。

4. 代码审查和讨论：
   团队其他成员（如同事、审查者或维护者）审查提交的代码，并在PR或MR的评论或讨论区提供反馈。开发者可以根据反馈继续改进代码。

5. 合并或关闭：

   • 如果代码审查成功，并且更改被接受，那么维护者或有权限的团队成员会合并这个请求，也就是将这个分支的更改合并到主分支。合并后的代码变更现在是项目代码的一部分。
   • 如果代码有问题或者不需要合并，PR或MR可以被关闭，相关的更改也就不会合并到主分支。

通过Pull Requests或Merge Requests，整个团队能够更有效地协作，增强代码质量控制，并保持代码库的整洁和组织性。此流程提供了一个透明、可审计的变更管理机制，使所有团队成员都能看到什么时候、为什么以及如何进行代码更改。