This project represents a virtual bare-bones development environment, ready to be raped with new software.
How to get going:
- Make a fork or copy the relevant files (
Vagrantfile,provisioning/*). - Have all the dependencies installed.
vagrant up.
By default, only one Ubuntu Budgie 18 VM is defined. But, many
machines using any number of configuration profiles (Vagrant box, static IP, et
cetera..) may easily be set up thru editing configuration values at the top in
the provided Vagrantfile. Furthermore, Ansible plumbing has been added to
facilitate machine provisioning. All of this is described in subsequent
sections.
This project was conceived by a Windows-addicted developer who got tired of hacking together new Vagrantfiles for each unique software project. I like to see it as a template replacement for "vagrant init".
Examples can be found in notes/examples.md. Also see dev-java.
Vagrant is used to run the Vagrantfile which uses a box that supports
two VM providers: VirtualBox and VMware Desktop.
VMware "Desktop" is Vagrant's catch-all phrase for VMware Fusion and VMware Workstation. Both of these effectively being the same product; the former is for MacOS and the latter is for Windows Linux. Soon we'll probably have a third code word that separate the Windows implementation from Linux - because, you know, being confusing is like best practice these days.
However that might be, Vagrant obviously needs to be installed together with at lesat one VM provider. If you go with VirtualBox, then you might also wanna put your hands on VirtualBox's extension pack (because decoupling an app into multiple binaries and distributions is like also best practice these days).
Ansible is not required to be installed on your host machine. See Machine provisioning with Ansible.
Default configuration values are replaced by editing the value of the
CONFIGURATION variable declared at the top of Vagrantfile.
By default, the Vagrantfile defines one configuration profile and one machine: [source]
CONFIGURATION = {
machines: 'my-ubuntu',
box: 'pristine/ubuntu-budgie-18-x64',
first_ip: '192.168.60.10',
cpus: Etc.nprocessors,
memory_mb: 4096
}
This is a very simple and straightforward case. One Ruby hash describes one profile and one String describes one machine using that profile. But, any number of profiles and any number of machines can be combined wrapping said entities in a Ruby Array. Here is an example that defines two profiles and three machines:
CONFIGURATION = {
machines: 'desktop',
box: 'pristine/ubuntu-budgie-18-x64',
first_ip: '192.168.60.10',
cpus: Etc.nprocessors,
memory_mb: 4096
}, {
machines: ['headless1', 'headless2'],
box: 'mhubbard/centos7',
first_ip: '192.168.60.11',
cpus: 2,
memory_mb: 512
}
Next, we go into details of the available configuration values that can be used.
Almost all values are required. The only ones being optional are
gui and ansible_group.
Defines machine names and thus implicitly, how many machines to create.
Can either be a String - one machine, or an Array of strings if the profile should be used to create multiple machines.
A machine name should not contain any whitespace.
The name is used as..
- hostname (you may use the name instead of an IP address when communicating between guest machines)
- Vagrant's machine name (what you see when you do
vagrant status) - VirtualBox's machine name (suffixed with the node's IP address in parenthesis)
Note: The IP is also supposed to be added to VMware's display name. But this does not appear to work (issue #21).
Defines which Vagrant box to use.
The value must be either the name of a locally installed box or the shorthand name of a box in Vagrant's cloud.
Defines the first static IP in a generated range of IPs used by the VMs on a private network.
If only one machine is defined, then only one IP will be used. Subsequent machines will get an IP similar to the previous machine's IP except the last byte will have been incremented by 1. For example, if multiple machines are defined and the default value is not changed, then the second machine will be assigned IP "192.168.60.11". The third machine will be assigned IP "192.168.60.12", and so on.
The IP will be appended to the machine's VirtualBox name and is thus clearly visible in the VirtualBox GUI's machine list.
For the VirtualBox provider, what Vagrant calls a "private network" is translated into NAT host-only (VirtualBox lingo, see VirtualBox docs). The NAT part enables Internet access from the VMs. The host-only part puts the host and VMs together on an internal network such that all machines can see each other. But, the outside world can not initiate a connection with anyone of the VMs.
The host IP on the internal network defaults to the network address ".1".
I.e., by default, unless the first_ip configuration is changed, this will be
192.168.60.1. [source]
What does a "private network" mean for the VMware provider? Who knows. It's certainly not on my high-priority list either since I consider this to be the responsibility of Vagrant to document (which they, of course, have not). I would guestimate the semantics should be the same as for VirtualBox. If you know something on this, please give me a holla.
Defines the number of virtual CPUs for the VM and is currently only applied for the VirtualBox provider.
By default, the value will be the number of available processors on the host machine (including logical cores).
There is a raging debate online as to how many virtual CPUs VirtualBox should assign to the VM. VirtualBox warns against using more CPUs than physical cores.. [source]
You should not, however, configure virtual machines to use more CPU cores than you have available physically (real cores, no hyperthreads).
..but does not care to provide an explanation.
Gorilla research uniformly points to a performance improvement using all available cores including logical [source1, source2, source3]. It appears that VirtualBox got spooked over reports that heavy CPU loads could erm.. crash VirtualBox [source1, source2]. So the "fix" was to simply discourage users from using all of their CPUs? Ultra lol!
Amount of RAM, in MiB, that the VM should allocate for itself from the host. This configuration is currently only applied to the VirtualBox provider.
Please note what VirtualBox has to say about this: [source]
The memory you give to the VM will not be available to your host OS while the VM is running, so do not specify more than you can spare.
If provided, then it must be either true or false depending on whether or
not you want a UI attached to the VM.
This value is specific to VirtualBox and should not "normally" have to be provided because the box sort of knows already if it comes with a desktop or not. But a great majority of all Vagrant boxes out there are a complete joke, to be honest, and they do not configure the VirtualBox provider accurately.
The default box used by this project does configure its provider properly and no action is needed.
This configuration value is optional and if provided, defines one Ansible
inventory group which comprises all the machines in the profile.
This project has some built-in Ansible plumbing to facilitate machine provisioning.
Ansible will be installed on the last machine defined, hereafter referred to as the "controller". This controller will then be used to provision all machines, including itself. Therefore, the host machine does not need to have Ansible installed.
Write Ansible plays in provisioning/playbook.yml.
Valid Ansible host patterns that can be used to target machines include - but are not limited to - machine names, IP and Ansible group.
Ansible roles can be automagically installed on the controller by putting them
in provisioning/requirements.yml.
Vagrant will run the ansible provisioner only once during the first "vagrant up" call. Vagrant will by default not - for better or worse - run provisioning again. But, if the initial provisioning crashed or you just feel like running the playbook a second time, do this:
vagrant provision --provision-with ansible
See CHANGELOG.md.
Copy paste whatever you want.