vocker can read Dockerfiles (currently just a subset), and does build VM images from them.
Instead of using the docker registry for base images, virt-builder
images can be used as FROM sources.
vocker is building the images incerementally, for each command. It caches the images, which makes it fast.
Note: This is WIP. Not all features are supported (yet).
A quick demo:
With more details:
$ pip install -rrequirements.txt
$ yum install virt-install
$ python setup.py installThe usage should look familiar:
$ vocker build --tag simple -f examples/Dockerfile.simple
$ vocker run simple
fast_fedora
$ vocker attach fast_fedora
# Export an image
$ vocker export simple -f simple.rawIn addition to the stock vocker tool, there is also a container and manifest to run vocker as a builder inside a Kubernetes cluster.
The use-case is to use vocker, to build an VM image "onto" a block PV.
The job definition is kept in the manifests/ directory.
In order to build a specific image, a vockerfile was to be written into the
vocker-job-source ConfigMap.
The ConfigMap is mapping a key to a vockerfile. The key will be used as the
resulting image filename, which will be written on to the target PV, which is
also defined in the Job definition.
In order to build you custom images, you need to complete the following steps:
- Add entry to ConfigMap
- Adjust Job to point to the PV to be populated
- Run job to generate images
An example ConfigMap (the name is relevant):
apiVersion: v1
kind: ConfigMap
metadata:
name: vocker-job-source
data:
Fedora: |
FROM fedora:26
MAINTAINER "Fabian Deutsch" <[email protected]>
ENV container docker
RUN echo Hello > /marker
EXPOSE 1234
CMD echo World >> /marker
Ubuntu: |
FROM ubuntu-16.04This ConfigMap would build two images Fedora and Ubuntu.
The usage then looks like:
$ kubectl apply -f manifests/vocker-builder-wo-presets.yaml
$ kubectl describe job vocker-builder
Name: vocker-builder
Namespace: default
Selector: controller-uid=ea99dbe6-fa05-11e7-a917-48b8902b170b
Labels: controller-uid=ea99dbe6-fa05-11e7-a917-48b8902b170b
job-name=vocker-builder
role=vocker-job
Annotations: ...
Parallelism: 1
Completions: 1
Start Time: Mon, 15 Jan 2018 16:08:17 +0100
Pods Statuses: 0 Running / 1 Succeeded / 0 Failed
Pod Template:
Labels: controller-uid=ea99dbe6-fa05-11e7-a917-48b8902b170b
job-name=vocker-builder
role=vocker-job
Containers:
vocker:
Image: quay.io/fabiand/vocker
Port: <none>
Environment: <none>
Mounts:
/source from vocker-source (rw)
/target from vocker-target (rw)
Volumes:
vocker-source:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: vocker-job-source
Optional: false
vocker-target:
Type: EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 40m job-controller Created pod: vocker-builder-xkckj
Once the pod has completed it's work, the image is ready on the PV.
When in the source folder:
$ pip install -rrequirements-dev.txtto install the dependencies.
$ python setup.py testto run the tests.
$ python vocker.py --helpto run your local developer version.
I think it's a nice approach to have a declarative approach for creating VMs.
By default a random root password is chosen. If you have to set the password during build time you can add the build instruction
RUN echo "mypass" | passwd --stdin
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent