.. _jail_think:

==================
Jail思考
==================

我在学习和使用FreeBSD Jail时，既感到这项技术的强大和轻巧，又感到有些困惑和迷思:

- 在大规模生产环境，使用 :ref:`thick_jail` 还是 :ref:`thin_jail` 优劣和成本，特别是海量jails环境，采用那种激素更适合运维更新
- 是否必须部署 :ref:`vnet_jail` 来实现网络的完全隔离以及复杂的防火墙，带来多大的收益，以及我能够完全掌控
- :ref:`linux_jail` 虽然美好，但是实践下来却遇到重重困难，有没有更好的最佳实践
- ...

我的想法
==========

.. note::

   这是我的当前观点，随着经验的积累以及深入学习，会不断调整

- 大规模部署生产环境，以 :ref:`thin_jail` 为主来部署应用服务器，但是关键数据服务器(底座)则采用 :ref:`thick_jail`

  - 应用服务器具有横向扩展能力，类似于 :ref:`kubernetes` 的无状态pod，每个服务器的Jail Templetes更新将带来所有依赖Jail的更新，可以降低存储成本以及运维成本
  
    - 但是关键在于合理的滚动更新，也就是类似配置管理分组进行，控制恒产不同阶段的灰度、小批量、大规模
    - 更新Template如何确保回滚
    - 如何监控更新的成功以及带来的业务影响

  - 数据服务器需要更为细粒度的控制更新，物理服务器更新Template导致整个系统大量依赖Jail的更新风险过高，所以采用 :ref:`thick_jail` 可以降低风险

    - 同样是如何控制更新的方案，或许需要寻找工具以及自己定制

- ZFS是大杀器:

  - 通过ZFS的快照copy和clone来构建Jail存储

    - ``RELEASE`` => ``RELEASE@base`` 快照
    - ``RELEASE@base`` 快照 => Clone出 ``base-ssh`` (这里只是一个案例，实际上可以按照生产应用来命名，例如数据库 ``pgsql-17.2`` 表示后续发布 :ref:`pgsql` 17.2版本 ) 并构建用户环境，所有修订完成后进行发布(也就是快照)
    - ``base-ssh@20250108-01`` 快照 => Clone出 **发布的Jails** ``dev-1``

  - **需要有一个工具进行大规模部署和运维** :ref:`openstack` / :ref:`openshift` ?
  - 大规模的数据备份和恢复，需要有演练方案

- :ref:`vnet_jail` 是生产必须的组件):

  - 提供了控制jail网络数据流的能力，不论是过滤防火墙还是流控，是生产环境必要的基础
  - VNET和ZFS类似，是FreeBSD的技术优势，可以在物理主机上构建的大量Jail
  - 即使个人使用的主机也应该采用，以便能够更好模拟

- :ref:`linux_jail` 可能尽量避免使用，究竟有那些应用必须在Linux上运行？