blubber.yaml: Bump pipeline version
Use v4 for blubber 0.8.0 Bump helm chart version for limitconfig causing failing "helm test". Change-Id: I850990920748ad80b59093d188a529ae916dc3f2
|il y a 10 mois|
|.pipeline||il y a 10 mois|
|api/openapi-spec||il y a 11 mois|
|build||il y a 1 an|
|cmd||il y a 11 mois|
|config||il y a 10 mois|
|docker||il y a 11 mois|
|docs||il y a 1 an|
|meta||il y a 2 ans|
|scripts||il y a 1 an|
|vendor||il y a 11 mois|
|.gitignore||il y a 1 an|
|.gitreview||il y a 1 an|
|CONTRIBUTING.md||il y a 1 an|
|Gopkg.lock||il y a 11 mois|
|Gopkg.toml||il y a 11 mois|
|LICENSE||il y a 3 ans|
|Makefile||il y a 10 mois|
|README.md||il y a 11 mois|
|VERSION||il y a 11 mois|
|blubber.example.yaml||il y a 11 mois|
|go.mod||il y a 1 an|
|policy.example.yaml||il y a 11 mois|
Very experimental proof of concept.
Blubber is a highly opinionated abstraction for container build configurations and a command-line compiler which currently supports outputting multi-stage Dockerfiles. It aims to provide a handful of declarative constructs that accomplish build configuration in a more secure and determinate way than running ad-hoc commands.
version: v4 base: debian:jessie apt: packages: [libjpeg, libyaml] lives: in: /srv/service runs: environment: FOO: bar BAR: baz variants: build: apt: packages: [libjpeg-dev, libyaml-dev] node: requirements: [package.json, package-lock.json] copies: [local] development: includes: [build] test: includes: [build] apt: packages: [chromium] entrypoint: [npm, test] prep: includes: [build] node: env: production production: base: debian:jessie-slim node: env: production copies: [prep] entrypoint: [node, server.js]
Blubber supports a concept of composeable configuration variants for defining slightly different container images while still maintaining a sufficient degree of parity between them. For example, images for development and testing may require some development and debugging packages which you wouldn’t want in production lest they contain vulnerabilities and somehow end up linked or included in the application runtime.
Properties declared at the top level are shared among all variants unless
redefined, and one variant can include the properties of others. Some
apt:packages are combined when inherited or included.
In the example configuration, the
test variant when expanded effectively
version: v4 base: debian:jessie apt: packages: [libjpeg, libyaml, libjpeg-dev, libyaml-dev, chromium] node: dependencies: true runs: in: /srv/service as: runuser uid: 666 gid: 666 entrypoint: [npm, test]
When trying to ensure optimally sized Docker images for production, there’s a common pattern that has emerged which is essentially to use one image for building an application and copying the resulting build artifacts to another much more optimized image, using the latter for production.
The Docker community has responded to this need by implementing
multi-stage builds and Blubber
makes use of this with its
copies configuration property.
In the example configuration, the
production variant declares artifacts to
be copied over from the result of building the
blubber command will be produce
Dockerfile output for the
blubber config.yaml variant
You can see the result of the example configuration by cloning this repo and running (assuming you have go):
make ./bin/blubber blubber blubber.example.yaml development ./bin/blubber blubber blubber.example.yaml test ./bin/blubber blubber blubber.example.yaml production
If you’d like to make code contributions to Blubber, see CONTRIBUTING.md.