enrich descrption

This commit is contained in:
steveej 2015-07-29 17:39:40 +02:00
parent 961e74e8f3
commit b5f1951076

View file

@ -1,32 +1,34 @@
# Package-Centric Source-Based Container Build System
## Reasons
## Problems to solve
* There's no standardized way to create container images that include
applications built from upstream sources.
* Application dependencies, which typically are libraries, are typically
* Application dependencies, which are mostly libraries, are typically
neglected when calculating container dependencies. This causes not knowing
what libraries are installed
* Ad-Hoc source builds are time consuming
## Goals
* Fast source builds with lots of packages available
* Ad-Hoc source builds if required but defaulting to binary repository
* Reproducible and shareable builds
* Customized Source configuration flags
* Container dependencies reflect dependencies of container applications
* Easy assembling and configuring of containers based on application packages
* Integrable with CI
* Portable
*Package based container builds*
This project aims to find a solution for creating and managing containers in a package-centric manner.
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 his container at runtime.
The specified container will have it's dependencies on packages which themselves can be packaged separately into one container per package.
*Source-based builds*
To allow maximum flexibility for the 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..
*Portable buildsystem*
As a portable system, builds can be processed locally on a users workstation or distributed to a bunch of servers.
*Shareable source and binaries*
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.
## Comparable
* Descriptive build spec. Examples:
* https://embedux.github.io/documentation/usage/rootfs/configuration.yml/index.html
* 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 darm
paper](http://www.researchgate.net/publication/228629017_The_Nix_Build_Farm_A_declarative_approach_to_continuous_integration)
* https://github.com/jordansissel/fpm/wiki
# Usage
@ -133,3 +135,14 @@ In case a sysadmin needs a patched and specifically configured version of it's f
Packaging Sysadmin42/nginx-production-1.7.6-p1 as ACI... [OK]
Uploading container spec and image(s) to 'mysuperbinhost' [OK]
```
# Implementation
### Things to start with
* Descriptive build spec. Examples:
* https://embedux.github.io/documentation/usage/rootfs/configuration.yml/index.html
* 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 darm
paper](http://www.researchgate.net/publication/228629017_The_Nix_Build_Farm_A_declarative_approach_to_continuous_integration)
* https://github.com/jordansissel/fpm/wiki