radial/wheel-coreos-pxe

语言: Shell

git: https://github.com/radial/wheel-coreos-pxe

用于运行dnsmasq的wheel存储库作为服务Coreos映像的PXE + DHCP服务器。
Wheel repository for running dnsmasq as PXE+DHCP server serving Coreos images.
README.md (中文)

Dockerfile-coreos,PXE

这是一个Radial Wheel存储库,用于将dnsmasq作为PXE + DHCP服务器服务运行 Coreos图片。

建立

  • 将您的公共ssh密钥添加到文件“hub / config / pxelinux.cfg / default”中   YOUR_SSH_PUBLIC_KEY_HERE说
  • 还要确保根据需要修改任何其他参数。他们不是     一个尺寸适合所有人。如果要使用cloud-config,则需要进行修改     这个文件很重要。请参阅CoreOS文档。
  • 在“hub / config / dnsmasq.conf”中配置dnsmasq配置以适合您的   网络。 必须在路由器上停用DHCP,并且不能使用其他DHCP服务器   运行。 这里的模板配置将dnsmasq设置为DNS,DHCP,tftp和   PXE服务器。至少,这个容器应该处理DHCP和   PXE。理论上你可以通过其他方式处理DNS和tftp(或者   其他容器),但这留给用户优化他们的   网络。 将其他配置文件放入“hub / config / dnsmasq.d”中   dns主机列表或其他配置分段。
  • 如果你有额外的文件/文件夹来烘焙核心图像(通常,   你可以创建一个在/ usr / share / oem中预加载的cloud-config.yml)   一个tarball(tarball的根与'/'相同),将其上传到   集线器并使用$ AMEND_IMAGE指定其位置。入口点脚本将   在提供之前自动修改它。

一个非常重要的注意事项:为了使DHCP正常工作,必须运行此容器 使用docker run --net host选项。此选项使用主机网络 堆栈作为容器拥有。这意味着您必须在dnsmasq中选择端口 配置不会与主机上已使用的任何端口冲突。 --net host选项不如其他选项安全,因此请务必使用 适当。

可调参数

可调环境变量;在运行时修改。斜体是默认值。

  • $ REFRESH_IMAGES:[True | False]刷新容器重启时的图像/文件。
  • $ CACHE_IMAGES:[True | False]存储下载的图像/文件;每个发布渠道一个。     在用于测试的释放通道之间切换时很有用
  • $ RELEASE:[“stable”|“beta”|“alpha”]下载/使用哪个版本。
  • $ SRV_DIR:[“/ data / tftpboot”]用于提供tftpboot文件的文件夹的路径。
  • $ CONF_FILE:[“/ config / dnsmasq.conf”] dnsmasq.conf文件的路径。
  • $ DNS_CHECK:[True | False]在尝试之前检查活动的D​​NS服务     下载任何东西在此实例中用于防止竞争条件     dnsmasq没有配置为处理DNS,而是另一个     容器/服务/机器是。
  • $ AMEND_IMAGE:[无]压缩或未压缩tarball的位置   在通过PXE提供之前与coreos映像合并。

径向

Radial是一种Docker容器拓扑策略 我们试图将Docker的最佳实践经验放入简单,可重复使用的版本中 可伸缩图像,dockerfiles和存储库。径向对容器进行分类 分为3种类型:车轴,轮毂和轮辐。 Wheel是用于重新创建的存储库 由三种类型的任意组合组成的应用程序堆栈 容器。查看Radial文档了解更多信息。

径向容器的主要设计目标之一是简单且无痛 模块化。所有Spoke(应用程序/二进制)容器都设计为运行 它们本身就是一种服务(一种由Hub容器组成的轮子,用于配置 和一个用于运行二进制文件的Spoke容器)或作为一个较大堆栈的一部分 许多Spoke的轮子都由Hub容器加入(数据库,应用程序 代码,Web服务器,后端服务等)。检查车轮 有关如何工作的更多详细信息的教程。

另请注意,目前,Radial使用Fig进行所有编排, 演示和测试。径向只是图像和图像的集合 策略,从技术上讲,任何编排工具都可以工作。但是图是 目前使用最简洁,最合理。

如何使用

静态构建

如果您需要修改入口点脚本,Dockerfile本身就可以创建 你的“配置”分支用于动态构建,或者只是想从中构建自己的分支 从头开始,您可以执行以下操作:

  1. 克隆此存储库
  2. 进行配置所需的任何更改并添加任何文件

动态构建

所有径向图像的标准功能是它们动态使用的能力。 这意味着要非常小心地将应用程序代码与之分开 它的配置,只要您使应用程序配置可用 作为一个git存储库,并在它自己的“配置”分支中按照指南 Wheel模板,不会构建任何图像 在部署时需要。这有许多好处,因为它允许快速部署 并且在构建过程中没有任何等待时间的配置。然而:

动态构建不会将配置文件提交到任何配置文件 结果图像像静态构建。

静态构建在暴露之前将文件“复制”到图像中 目录作为卷。动态构建在运行时进行git提取 结果数据被下载到现有的卷位置,即 现在免于Docker版本控制。这两种方法都有其优点和优点 缺点。部署相同的确切配置可能会受益于 单个图像静态构建,而部署许多不同的一次性 快速配置最好动态完成,没有建筑物。

要动态运行:

  1. 修改fig-dynamic.yml文件以指向您自己的Wheel存储库    通过设置$ WHEEL_REPO变量来定位。运行时,Hub容器    将拉出该存储库的“config”分支并使用它来运行Spoke    具有您自己配置的容器。
  2. fig -f fig-dynamic.yml up

执照

WITH

积分

非常感谢JérômePetazzoni PXE,这个容器主要基于此 的。

本文使用googletrans自动翻译,仅供参考, 原文来自github.com

en_README.md

Dockerfile-coreos-pxe

This is a Radial Wheel repository for running dnsmasq as PXE+DHCP server serving
Coreos images.

Setup

  • Add your public ssh-key to the file "hub/config/pxelinux.cfg/default" where it
    says YOUR_SSH_PUBLIC_KEY_HERE
  • Also make sure to modify any of the other parameters as needed. They aren't
    one-size-fits-all. If you want to use cloud-config, you will need to modify
    this file heavily. Refer to the CoreOS documentation for that.
  • Configure dnsmasq configuration in "hub/config/dnsmasq.conf" to suit your
    network.
    • DHCP must be deactivated on your router and no other DHCP server can be
      running.
    • The template configuration here has dnsmasq setup as DNS, DHCP, tftp and
      PXE server. At the bare minimum, this container should handle DHCP and
      PXE. You could theoretically have DNS and tftp handled by other means (or
      other containers), but thats left up to the user to optimize for their
      network.
    • Drop in additional configuration files into "hub/config/dnsmasq.d" for
      lists of dns hosts or other configuration segmenting.
  • If you have additional files/folders to bake into the coreos image (typically,
    a pre-loaded cloud-config.yml in /usr/share/oem for example), you can create
    a tarball (with the root of the tarball the same as '/'), upload it into the
    hub and specify it's location with $AMEND_IMAGE. The entrypoint script will
    automatically amend it before serving it out.

A very important note: in order for DHCP to work, this container must run
using the docker run --net host option.
This option uses the hosts network
stack as the containers own. That means you must choose ports in your dnsmasq
configuration that will not conflict with any ports already used on the host.
The --net host option is not as secure as other options, so make sure to use
appropriately.

Tunables

Tunable environment variables; modify at runtime. Italics are defaults.

  • $REFRESH_IMAGES: [True|False] Refresh images/files on container restart.
  • $CACHE_IMAGES: [True|False] Store downloaded images/files; one per release channel.
    Useful when switching between release channels for testing.
  • $RELEASE: ["stable"|"beta"|"alpha"] Which release to download/use.
  • $SRV_DIR: ["/data/tftpboot"] Path for the folder to serve the tftpboot files from.
  • $CONF_FILE: ["/config/dnsmasq.conf"] Path to dnsmasq.conf file.
  • $DNS_CHECK: [True|False] Check for an active DNS service before attempting to
    download anything. Useful in preventing race conditions when this instance
    of dnsmasq is not configured to handle DNS, but another
    container/service/machine is.
  • $AMEND_IMAGE: [nothing] Location of compressed or uncompressed tarball
    to merge with the coreos image before serving it via PXE.

Radial

Radial is a Docker container topology strategy that
seeks to put the canon of Docker best-practices into simple, re-usable, and
scalable images, dockerfiles, and repositories. Radial categorizes containers
into 3 types: Axles, Hubs, and Spokes. A Wheel is a repository used to recreate
an application stack consisting of any combination of all three types of
containers. Check out the Radial documentation for more.

One of the main design goals of Radial containers is simple and painless
modularity. All Spoke (application/binary) containers are designed to be run by
themselves as a service (a Wheel consisting of a Hub container for configuration
and a Spoke container for the running binary) or as part of a larger stack as a
Wheel of many Spokes all joined by the Hub container (database, application
code, web server, backend services etc.). Check out the Wheel
tutorial
for some more details on how this works.

Note also that for now, Radial makes use of Fig for all orchestration,
demonstration, and testing. Radial is just a collection of images and
strategies, so technically, any orchestration tool can work. But Fig was the
leanest and most logical to use for now.

How to Use

Static Build

In case you need to modify the entrypoint script, the Dockerfile itself, create
your "config" branch for dynamic building, or just prefer to build your own from
scratch, then you can do the following:

  1. Clone this repository
  2. Make whatever changes needed to configuration and add whatever files
  3. fig up

Dynamic Build

A standard feature of all Radial images is their ability to be used dynamically.
This means that since great care is made to separate the application code from
it's configuration, as long as you make your application configuration available
as a git repository, and in it's own "config" branch as per the guidelines in
the Wheel template, no building of any images will be
necessary at deploy time. This has many benefits as it allows rapid deployment
and configuration without any wait time in the building process. However:

Dynamic builds will not commit your configuration files into any
resulting images like static builds.

Static builds do a "COPY" of files into the image before exposing the
directories as volumes. Dynamic builds do a git fetch at run time and the
resulting data is downloaded to an already existing volume location, which is
now free from Docker versioning. Both methods have their advantages and
disadvantages. Deploying the same exact configuration might benefit from a
single image built statically whereas deploying many different disposable
configurations rapidly are best done dynamically with no building.

To run dynamically:

  1. Modify the fig-dynamic.yml file to point at your own Wheel repository
    location by setting the $WHEEL_REPO variable. When run, the Hub container
    will pull the "config" branch of that repository and use it to run the Spoke
    container with your own configuration.
  2. fig -f fig-dynamic.yml up

License

MIT

Credits

Much thanks to Jérôme Petazzoni for
PXE, which this container is mainly based off
of.