|
|
||
|---|---|---|
| nginx-prod | ||
| src/docs | ||
| .gitignore | ||
| README.md | ||
| shell.nix | ||
Package-Centric Source-Based Container Build System
Motivation
- There's no standardized way to create container images that include applications built from upstream sources.
- No standardized way to share artifacts for containers instead of whole containers
- Application dependencies, which are mostly libraries, are typically neglected when calculating container dependencies. This causes not knowing what libraries are installed
Features
Package-based container builds
This project aims to find a solution for creating and managing containers in a package-centric manner. In this context a package is both a definition of how to build (e.g. a Gentoo ebuild or Debian control file) Every container will be able to specify their dependencies, which can be self-built packages or exact versions of already existing packages. Like this the user will always exactly know what libraries, files, etc. is available to their container at runtime. The specified container will have its dependencies on packages which themselves can be packaged separately into one container per package.
Source-based builds
To allow maximum flexibility for users, the package files must be able to describe source builds, which allows the user to make changes to the source before the package is built and integrated into the target container image.
Reproducibility
Builds of packages, as well as builds of container images, must be reproducible in a way that the same input always yields the same output. Because every change of a package yields in a different identity, the system allows to have multiple versions of one software application. These can differ in properties like source code patches, build configuration options, target architecture, etc..
Portability of the whole system
As a portable system, builds can be processed locally on a user's workstation or distributed to a bunch of servers.
Shareable source and binary files
The build system will ship tools that make it easy to discover and share source and binary files that are respectively consumed and produced by the build system. This will allow for very fast setups of containers that involve only downloading from trusted repositories.
Usage
Buildit configuration
.buildit-config.yaml
---
repository:
name: mysuperbinhost
upload-type: ssh
upload-path: containers@mysuperbinhost.org/containers
download-type: https
download-path: mysuperbinhost.org/containers
Sysadmin needs patched nginx
Sysadmin
In case a sysadmin needs a patched and specifically configured version of its favorite webserver nginx.
-
Put directories and files in place
Directory layout
├── nginx-prod │ ├── container.yaml │ ├── files │ │ └── nginx.conf │ └── pkgs │ └── nginx │ ├── patches │ │ └── https-only.patch │ └── pkg.yaml
pkg.yaml
--- base: www-servers/nginx-1.7.6 author: Sysadmin42 <sys@admin42.org> patches: patches/https-only.patch: "This patch denies all plain http requests" https://github.com/nginx/nginx/commit/52e4dc2f74fd032dace01acbe5eb29ddf7c1ad96.patch: "Fix buffer overruns" use: with: - ipv6 - selinux
container.yaml
--- - vars: author: Sysadmin42 name: nginx-production version: 1.7.6-p1 os: linux arch: amd64 - package: type: embedded path: ./pkgs/nginx - sync: src: ./files/nginx.conf dest: /etc/nginx/nginx.conf recursive: True chmod: 0644 - image: type: aci content: | { "acKind": "ImageManifest", "acVersion": "0.6.1", "name": "{{ name }}-{{ version }}", "labels": [ {"name": "os", "value": "{{ os }}"}, {"name": "arch", "value": "{{ arch }}"} ], "app": { "exec": [ "/sbin/nginx" ], "user": "0", "group": "0" } } -
Build the container
$ buildit nginx-prod/ --discover=github.com/sysadmin42/containers,push=True Building Sysadmin42/nginx-production-1.7.6-p1 Processing package from './pkgs/nginx' for linux/amd64. HASH: 86c8ef43-f4a4-49ba-a0ee-92900211c7b6 Can't find HASH in any known location... Defaulting to local build... [OK] Uploading packages to 'mysuperbinhost' [OK] Packaging Sysadmin42/nginx-production-1.7.6-p1 as ACI... [OK] Uploading container spec and image(s) to 'mysuperbinhost' [OK]
Implementation
Resources
CoreOS related tools
Similar Projects
- Previous work of mine: https://embedux.github.io/documentation/usage/rootfs/configuration.yml/index.html
Operating Systems and Package managers
- http://nixos.org/nixos/about.html
- https://gitweb.gentoo.org/proj/releng.git/tree/releases/weekly/specs/amd64?id=HEAD
- https://github.com/zefhemel/nix-docker
- nix build farm paper
- https://blogs.gentoo.org/zmedico/2015/07/06/tardelta-generate-a-tarball-of-differences-between-two-tarballs/
- https://github.com/jordansissel/fpm/wiki
Outlook
The completion of the described container build system will benefit greatly to how container images can be shared and deployed.
Trusted Containers by reproducibility
Trusting container images has been hard. Being able to reproduce and verify the builds improves this.
Obsolete Container-Vulnerabilities Scans
Vulnerabilities scans are only necessary if it's unknown what the container image contains. With the new build system the build specification allows to inspect the included container images much more efficiently. Image vendors can directly track contained packages and their CVEs instead of relying on posteriori scans.
Automatic Container Updates
When identified, regular and security updates to 3rd party packages can trigger rebuilds as well as changed source files of 1st party applications. The update circle can be closed by automatically deploying new containers triggered by the updated images. Complete automation might be difficult in real-world deployments because software updates sometimes require configuration changes.