在车里雅宾斯克，举行了Sysadminka系统管理员会议，最后，他们就如何在Kubernetes中使用1C-Bitrix上的应用程序的解决方案作了报告。
Bitrix，Kubernetes，Ceph-很棒的组合吗？
我将告诉您我们如何将所有这些整合在一起。
走吧
米塔普于4月18日在车里雅宾斯克举行。 您可以在Timepad中阅读有关我们的mitap的内容，并在YouTube上观看 。
如果您想通过报告或作为听众来找我们-欢迎来到Wellcome，请致信vadim.isakanov@gmail.com和Telegram t.me/vadimisakanov。
我的报告
滑梯
Kubernetes Southbridge 1.0解决方案中的Bitrix
我将按照在会议上所做的那样，以“针对Kubernetes中的虚拟对象”的格式讨论我们的解决方案。 但我想至少在Wikipedia文章级别上，您会知道Bitrix，Docker，Kubernetes，Ceph这两个词。
您对Kubernetes中的Bitrix有什么了解？
在Internet上，关于Kubernetes中Bitrix上应用程序的操作的信息很少。
我只找到这样的材料：
Qsoft的Alexander Serbul，1C-Bitrix和Anton Tuzlukov的报告：
我建议听。
由Habré上的用户Serkyron开发自己的解决方案。
我也找到了这样的解决方案 。
III ...实际上。
我警告您，我们没有使用上面的链接检查解决方案的质量：-)
顺便说一下，在准备我们的解决方案时，我与Alexander Serbul进行了交谈，当时他的报告还没有，所以在我的幻灯片中有“ Bitrix不使用Kubernetes”项。
但是已经有很多现成的Docker映像供Bitrix在Docker中工作： https ://hub.docker.com/search?q=bitrix&type=image
这足以在Kubernetes中创建完整的Bitrix解决方案吗？
不行 有很多问题需要解决。
Kubernetes中Bitrix有什么问题？
首先-Dockerhub现成的映像不适合Kubernetes
如果我们要构建一个微服务架构（通常在Kubernetes中需要），则需要将Kubernetes中的应用程序划分为多个容器，并确保每个容器都执行一个小功能（并且做得很好）。 为什么只有一个？ 简而言之-更简单，更可靠。
如果要更真实，请查看本文和视频，请访问： https : //habr.com/en/company/southbridge/blog/426637/
Dockerhub中的Docker映像主要基于“多合一”原理构建，因此我们仍然必须自己动手甚至从头开始创建映像。
其次-网站代码是从管理面板中编辑的
我们在网站上创建了一个新部分-代码已更新（添加了具有新部分名称的目录）。
从管理面板更改了组件属性-代码已更改。
Kubernetes“默认”不知道如何使用它，容器必须是无状态的。
原因：群集中的每个容器（子）仅处理部分流量。 如果仅在一个容器（底部）中更改代码，则在不同的窗格中，代码将不同，站点将以不同的方式工作，站点的不同版本将显示给不同的用户。 你不能那样生活。
第三-您需要解决部署问题
如果我们有一个整体和一个“经典”服务器，那么一切都非常简单：我们部署一个新的代码库，迁移数据库，将流量切换到新版本的代码。 切换立即发生。
如果我们在Kubernetes中有一个网站，它被锯成微服务，那么会有许多带有代码的容器。 您需要使用新版本的代码来收集容器，将其替换为旧的容器，正确执行数据库迁移，并且最好对访问者隐式地进行。 幸运的是，Kubernetes在这方面为我们提供了帮助，它支持整个不同类型的部署云。
第四-您需要解决静态存储的问题
如果您的站点仅重10 GB，并且完全将其部署在容器中，则将获得重10 GB的容器，这些容器将永远被部署。
您需要将站点中最“繁重”的部分存储在容器之外，而问题出在如何正确执行
我们的决定中没有什么
完整的微功能/微服务Bitrix代码没有被削减（因此注册是分开的，在线商店的模块是分开的，等等）。 我们将整个代码库存储在每个容器中。
我们也不会将库存储在Kubernetes中（不过我还是在Kubernetes中为开发人员环境（而不是生产环境）实现了基于库的解决方案）。
网站管理员仍然会注意到该网站可以在Kubernetes中运行。 “系统检查”功能无法正常运行，要从管理面板编辑站点代码，必须首先单击“我要编辑代码”按钮。
我们确定了问题，确定了实现微服务的必要性，目标很明确-获得一个可在Kubernetes中处理Bitrix应用程序的工作系统，同时保留Bitrix的功能和Kubernetes的优势。 我们开始执行。
建筑学
Web服务器（工作人员）有很多“工作”的壁炉。
一顶冠下（可能只有一个）。
一种从管理面板编辑站点代码的升级（也只需一项）。
我们解决问题：
- 会话存储在哪里？
- 在哪里存储缓存？
- 在哪里存储静态变量，而不是在容器堆中放置千兆字节的静态变量
- 数据库将如何工作？
Docker镜像
我们首先构建一个Docker映像。
理想的选择是拥有一个通用映像，在此基础上，我们可以同时获得工作区，带有括号的区和升级区。
我们就是这样拍的 。
它包括nginx，apache / php-fpm（可在汇编过程中选择），用于发送邮件的msmtp和cron。
组装图像时，该站点的完整代码库将复制到/ app目录（除了那些放在单独的共享存储中的部分）。
微服务，服务
工人炉膛：
- Nginx + Apache / php-fpm + msmtp容器的容器
- msmtp没有在单独的微服务中解决，Bitrix开始怨恨它无法直接发送邮件
- 每个容器都有完整的代码库。
- 禁止更改容器中的代码。
cron下：
- 带有Apache，PHP，Cron的容器
- 包括完整的代码库
- 禁止更改容器中的代码
升级下：
- Nginx + Apache / php-fpm + msmtp容器的容器
- 没有禁止更改容器中的代码的禁令
会话存储
Bitrix缓存存储
更重要的是：我们存储密码，以连接到数据库到kubernetes机密邮件中的所有内容。 我们获得了奖励，密码仅对我们授予机密访问权限的人员可见，而对有权访问该项目代码库的每个人都不可见。
静态储存
您可以使用任何东西：ceph，nfs（但不建议在生产中使用nfs），来自“云”提供商的网络存储等。
该存储将需要通过容器连接到站点的/ upload /目录以及其他具有静态目录的目录。
资料库
为了简单起见，我们建议将基础移到Kubernetes之外。 Kubernetes的基础是一个单独的复杂任务，它将使电路变得更加复杂。
会话存储
我们使用memcached :)
它在存储会话，群集方面做得很好，并且在php中作为session.save_path本身受支持。 当我们用大量的Web服务器构建集群时，这种系统在经典的整体架构中已经被设计了很多次。 对于部署，我们使用头盔。
$ helm install stable/memcached --name session
php.ini-图像设置中的此处设置用于在memcached中存储会话
我们使用环境变量通过memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/传输主机数据。
这使您可以在dev，stage，test，prod等环境中使用相同的代码（其中的内存缓存主机名称将有所不同，因此我们需要将会话的唯一主机名传输到每个环境）。
Bitrix缓存存储
我们需要一个故障安全存储，所有炉膛都可以在其中写入，并且可以从中读取。
我们还使用memcached。
Bitrix自己推荐此解决方案。
$ helm install stable/memcached --name cache
bitrix / .settings_extra.php-在Bitrix中，此处设置了我们存储缓存的位置
我们还使用环境变量。
克龙塔斯基
在Kubernetes中执行crontab的方法有很多。
您可以争论最正确的方法，但是在这种情况下，我们选择了选项“将Pod与crontask分开部署”
怎么做：
- 通过ConfigMap或通过config / addcron添加王冠
- 在一种情况下，运行一个与worker sub相同的容器+允许在其中执行Crown任务
- 使用相同的代码库，由于统一，容器的组装很简单
我们得到什么好处：
- 我们在与开发环境相同的环境中使用crontaski（docker）
- Krontaski无需为Kubernetes进行“重写”，它们的工作方式与以前相同，并且代码库相同
- 王冠成员可以将具有提交权限的所有团队成员添加到生产分支，而不仅仅是管理员
南桥K8SDeploy模块和从管理面板编辑代码
我们在谈论升级吗？
以及如何将交通引向那里？
Hooray，我们在php中为此编写了一个模块：)这是Bitrix的经典小模块。 它尚未公开可用，但我们计划将其打开。
该模块在Bitrix中作为常规模块安装：
它看起来像这样：
它允许您设置一个cookie，该cookie可以标识站点管理员并允许Kubernetes发送要升级的流量。
更改完成后，您需要单击git push，代码更改将发送到git，然后系统将使用新版本的代码收集映像，并将其“滚动”到整个群集中，以替换旧的pod。
是的，这有点曲折，但同时，我们维护微服务架构，并且不要让Bitrix用户有机会通过管理面板更正代码。 最后，这是一个选项，您可以用其他方式解决编辑代码的问题。
舵图
为了在Kubernetes中构建应用程序，我们通常使用Helm软件包管理器。
对于我们在Kubernetes的Bitrix解决方案，我们的首席系统管理员Sergey Bondarev编写了一个特殊的Helm图表。
它构建了worker，ugrade，cron炉床，配置入口，服务，将变量从Kubernetes机密传递到炉床。
我们将代码存储在Gitlab中，并且还运行来自Gitlab的Helm程序集。
简而言之，看起来像这样
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production
如果在部署过程中出现问题，Helm还允许您进行“无缝”回滚。 当您不必慌乱地“为ftp修复代码，因为产品已掉落”，而Kubernetes会自动执行它而又不会造成停机时，这真是太好了。
部署
是的，我们是Gitlab＆Gitlab CI的粉丝，请使用它:)
当在项目存储库中提交到Gitlab时，Gitlab启动一个管道，该管道将部署新版本的环境。
阶段：
- 构建（构建新的Docker映像）
- 测试（测试）
- 清理（删除测试环境）
- 推送（发送到Docker注册表）
- 部署（我们通过Helm在Kubernetes中部署应用程序）。
华友世纪，我们准备介绍它！
好吧，或者问问题，如果有的话。
那我们做了什么
从技术角度来看：
- dockerized Bitrix;
- 将Bitrix“切割”到容器中，每个容器执行最少的功能；
- 实现容器的无状态状态；
- 解决了在Kubernetes中更新Bitrix的问题;
- Bitrix的所有功能继续起作用（几乎所有功能）；
- 在Kubernetes中进行了部署并在版本之间进行了回滚。
从业务角度来看：
- 容错
- Kubernetes工具（易于与Gitlab CI集成，无缝部署等）；
- 秘密密码（仅对那些直接授予密码访问权限的用户可见）；
- 在单个基础架构中创建其他环境（用于开发，测试等）非常方便。