Packer templates for CentOS
Overview
This repository contains Packer templates for creating CentOS Vagrant boxes. It's a fork of the [Boxcutter/CentOS] repo with some small amount of customisation.
Building the Vagrant boxes with Packer
To build all the boxes, you will need VirtualBox, VMware Fusion/VMware Workstation and Parallels installed.
Parallels requires that the Parallels Virtualization SDK for Mac be installed as an additional prerequisite.
We make use of JSON files containing user variables to build specific versions of CentOS.
You tell packer
to use a specific user variable file via the -var-file=
command line
option. This will override the default options on the core centos.json
packer template,
which builds CentOS 7 by default.
For example, to build CentOS 7, use the following:
$ packer build -var-file=centos7.json centos.json
If you want to make boxes for a specific desktop virtualization platform, use the -only
parameter. For example, to build CentOS 7 for VirtualBox:
$ packer build -only=virtualbox-iso -var-file=centos7.json centos.json
To perform a 'headless' VirtualBox build:
$ packer build -var 'headless=true' -only=virtualbox-iso -var-file=centos7.json centos.json
Or to build for VMware-based hypervisors:
$ packer build -only=vmware-iso -var-file=centos7.json centos.json
The boxcutter templates currently support the following desktop virtualization strings:
parallels-iso
- Parallels desktop virtualization (Requires the Pro Edition - Desktop edition won't work)virtualbox-iso
- VirtualBox desktop virtualizationvmware-iso
- VMware Fusion or VMware Workstation desktop virtualization
Building the Vagrant boxes with the box script
We've also provided a wrapper script bin/box
for ease of use, so alternatively, you can use
the following to build CentOS 7 for all providers:
$ bin/box build centos7
Or if you just want to build CentOS 7 for VirtualBox:
$ bin/box build centos7 virtualbox
Building the Vagrant boxes with the Makefile
A GNU Make Makefile
drives a complete basebox creation pipeline with the following stages:
build
- Create basebox*.box
filesassure
- Verify that the basebox*.box
files produced function correctlydeliver
- Upload*.box
files to Artifactory, Atlas or an S3 bucket
The pipeline is driven via the following targets, making it easy for you to include them in your favourite CI tool:
make build # Build all available box types
make assure # Run tests against all the boxes
make deliver # Upload box artifacts to a repository
make clean # Clean up build detritus
Proxy Settings
The templates respect the following network proxy environment variables and forward them on to the virtual machine environment during the box creation process, should you be using a proxy:
- http_proxy
- https_proxy
- ftp_proxy
- rsync_proxy
- no_proxy
Tests
The tests are written in Serverspec and require the
vagrant-serverspec
plugin to be installed with:
vagrant plugin install vagrant-serverspec
The Makefile
has individual targets for each box type with the prefix
test-*
should you wish to run tests individually for each box. For example:
make test-virtualbox/centos66-nocm.box
Similarly there are targets with the prefix ssh-*
for registering a
newly-built box with vagrant and for logging in using just one command to
do exploratory testing. For example, to do exploratory testing
on the VirtualBox training environmnet, run the following command:
make ssh-virtualbox/centos66-nocm.box
Upon logout make ssh-*
will automatically de-register the box as well.
Contributing
- Fork and clone the repo.
- Create a new branch, please don't work in your
master
branch directly. - Add new Serverspec or Bats tests in the
test/
subtree for the change you want to make. Runmake test
on a relevant template to see the tests fail (likemake test-virtualbox/centos65
). - Fix stuff. Use
make ssh
to interactively test your box (likemake ssh-virtualbox/centos65
). - Run
make test
on a relevant template (likemake test-virtualbox/centos65
) to see if the tests pass. Repeat steps 3-5 until done. - Update
README.md
andAUTHORS
to reflect any changes. - If you have a large change in mind, it is still preferred that you split them into small commits. Good commit messages are important. The git documentation project has some nice guidelines on writing descriptive commit messages.
- Push to your fork and submit a pull request.
- Once submitted, a full
make test
run will be performed against your change in the build farm. You will be notified if the test suite fails.
Acknowledgments
Thanks to upstream contributors to the Boxcutter repositories.