martinandersson / dev-mini Goto Github PK

View Code? Open in Web Editor NEW

5.0 1.0 2.0 73 KB

A minimal development environment.

License: The Unlicense

vagrant vagrantfile vagrant-environments vagrant-template virtual-machine virtualbox-machine

dev-mini's Introduction

A minimal development environment

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 minimal install of Ubuntu Budgie 19.04 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.

Dependencies

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.

Configuration

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-19.04',
  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-19.04',
  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.

`machines`

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).

`box`

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.

`first_ip`

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.

`cpus`

Defines the number of virtual CPUs for the VM.

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!

`memory_mb`

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.

`gui`

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.

`ansible_group`

This configuration value is optional and if provided, defines one Ansible inventory group which comprises all the machines in the profile.

Machine provisioning with Ansible

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.

The provided playbook will upgrade the system and install a text editor (gedit). Feel free to replace this guy or extend him by throwing in whatever packages and apps you need for your environment.

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

Change log

See CHANGELOG.md.

License

Copy paste whatever you want.

Contact

martinandersson.com/contact

dev-mini's People

Contributors

Stargazers

Watchers

Forkers

ekinertac vkozyrev

dev-mini's Issues

Speed up master

The current desktop box has very slow performance.

It works okay in low resolution, but switching over to full-screen on my high-res monitor and the windows and keyboard start lagging. With this lag, it's even hard to type in a code editor!

Other than this lag, video playback works okay. It suffers a bit tearing but that's okay. Audio is sometimes choppy but at least there's no delay so the audio is actually very pleasant.

Again, overall good experience but laggy GUI and keyboard.

I think there are primarily two reasons for this.

Ubuntu's default desktop (GNOME 3.26.1) is most likely extremely bloated.
I suspect the Guest Additions has not been properly installed.

Either way, would be cool to explore alternative boxes and/or replace the desktop. Here's a few research-friendly buzz words:

Budgie.
MATE with Brisk menu.
Pantheon (used by Elementary OS)
Deepin
KDE neon
Fedora
Cinnamon 3
Xubuntu
Lubuntu

Also, google "linux distros" and one can browse 'em directly in the search results as if they were nearby movie showtimes! lol.

Here's a good link from Ubunto.com on how to build an Ubuntu from scratch.

Read keyboard layout from the host machine

The user shouldn't have to hack a configuration value for this.

Lazily install dependent plugins

Try to install dependent plugins only on vagrant up. Currently, this is done as soon as the user and his Vagrant daemon interact with the Vagrantfile, for example on vagrant status. This could be confusing, to say the least!

Link project folder from desktop

First, complete #6 and if we're still left with a desktop, put a link to the synced project folder on the desktop.

Make the ip_start configuration specify four bytes

Currently, a private network's IP is specified using the first three bytes. But there's really no reason to not let the user specify four bytes. I.e., 10.20.30.40.

An explicit declaration is always easier to understand and will also remove the need to document the implicit last byte; currently being 10.

While improving the docs, also toss in a few comments about the host ip/default gateway, subnet mask NAT, host-only et cetera. You know, all those things Vagrant forgot to document.

Provide an ability in the configuration option to specify synced folders

..could be implemented something like this around line 50 (but make plural):

machine.vm.synced_folder 'D:\My\GitHub', '/vm/github'

Pull my personal desktop preferences

Would be so great if I could have the desktop machine fade the screen after 20 minutes, turn off the screen after 25 minutes and never lock the screen.

Can not vagrant reload on an Ubuntu host

The current project works just fine on Windows hosts but fails on the second vagrant up on Ubuntu hosts.

What happens - again, only on Ubuntu hosts - is that Vagrant/VirtualBox/Whoever deletes the VM folder (~/VirtualBox VMs/my-ubuntu [192.168.60.10] (saw light 2018-02-24)/) and of course, this dramatically halts the process of getting the machine to run lol.

The crash (and solution) is just the same as the one reported here: https://stackoverflow.com/q/24689963

Removing the "[]" from the VirtualBox machine name makes it work. These are completely legal folder name characters on both Windows and Linux, but then.. Vagrant and Ruby is what it is.

Change configuration model

Rethink how master and slaves are configured, maybe we want any number of x/y/z machines which we can call "profiles"?

For example, maybe user wants to do something like this:

PROFILES = {
  big_and_juicy: {
    machines: 'my-desktop-singleton',
    ip_start: '192.168.60.10',
    box: 'fat/box',
    memory: 9999
    ...
  },
  micromachines: {
    machines: ['headless-1', 'headless-2'],
    ip_start: '192.168.60.11',
    box: 'thin/box',
    memory: 128
    ...
  }
}

In this example, we have two profiles; big_and_juicy and micromachines which uniquely define a bunch of configuration values. And then.. the user can instantiate any number of machines per profile. Plus the profile names can become the host groups for Ansible.

Maybe renaming the CONFIGURATION variable name is not a good idea. Or maybe it is a good idea but GROUPS or something else would be a better choice. Need external brains on this.

Apart from the obvious benefit to the user, I think this will - if done correctly - will simplify the docs which basically repeat a bunch of configuration values. We would only have to describe "memory" and "cpus" one time so to speak =)

Pin the terminal to favorites bar

First, complete #6 and if we're still left with a favorites bar, then pin/link the terminal.

Determine max memory allocation

Reserving 4 GB on the host is not being kind. Should probably keep within a range, falling back on hosts with less installed RAM.

Disable 2D video acceleration and enable 3D acceleration

Switch the VirtualBox options accelerate3d and accelerate2dvideo with each other. Currently, 3D is off and 2D is on.

3D

VirtualBox claims they will pick "sensible defaults" and that 3D support is "experimental".

I am always reserved towards whatever it is that VirtualBox thinks is a good default value. Plus, I have noted that if a feature is not supported they tend do disable it automagically. I have personally not experienced any issues related to the 3D acceleration other when trying out some really weird boxes. Having that said, nor have I ever noted a performance boost with the thing enabled.

My experience tells me that most ppl recommend to turn on 3D acceleration (example) and I also know it is widely known in the community to disable 3D if the GUI acts up.

So my final conclusion is that as long as 3D acceleration works with the current box and my Windows host then I am happy.

2D video

..is only supported "for Windows guests" and I have definitely not seen a performance improvement having this thing enabled. So who cares, turn it off.

Add a problem description

Add a description in the README.md file which describes the problem this project is trying to solve.

Upgrade Ansible

Title says it all.

Also, we're prolly gonna have to remove the folder-write-permissions hack after the upgrade and change the roles' path from /etc/ansible/roles/ to /home/vagrant/.ansible/roles/.

They (Ansible) have added the new path as prioritized over the old (GitHub commit).

In theory, it should still be legit business to use the old path together with the necessary hack, but I tried to do a quick upgrade on my local machine and somehow the paths got screwed up. Was it that ansible-galaxy installed into A but ansible looked in B and couldn't find the role? Can't remember. Either way, getting rid of hacks is, of course, a favorable choice.

Does the VMware provider use a linked clone, or not?

The current Vagrantfile (v2.1.0) configures VirtualBox to use a linked clone:

vb.linked_cone = true

According to Vagrant's docs, this defaults to true for the VMware provider- which is why it has not been explicitly configured in the Vagrantfile.

But.. after my experience with Vagrant, I simply can not trust anything they claim these days. Confirm whether or not this is true. If not, then please configure linked clones for VMware as well.

Determine max CPUs

The slaves have a default configuration value of 2 CPUs. What if the host only has one? Or even worse, HALF A CPU! What happens then?

Obviously, we need to think this thru.

The fix could probably be released together with the fix for #1.

VirtualBox machine name insinuates the machine was created same day

The VirtualBox machine name has a creation date stamp in it, which used to work. But at some point, Vagrant decided to start renaming the machine if the Vagrantfile indicated a new machine name. This I would say is something very intuitive, but it means we can no longer keep a creation date stamp in the machine name. Unless the Vagrantfile sort of figures out on his own that the machine is already created and reuse that old date stamp instead of generating a new based on today's date. Given that we're already having problems with the machine name (#18), I think it's better, for now, to just drop the date stamp.

Install a text editor

Preferably gedit.

Consider switching slave nodes' CentOS for Alpine Linux

Add pros and cons here?

Vagrant's public key is not removed?

So we should remove it ourselves, from ~/.ssh/authorized_keys.

See this (a closed issue, i.e., file a new Vagrant issue): hashicorp/vagrant#6930

What's going on with VMware's display name?

Supposedly, VMware should, just as is the case for VirtualBox, get the IP added as a suffix to the machine's display name. This is a copy-paste from the current Vagrantfile (v2.1.0):

v.vmx['displayname'] = name + " (#{ip})"

..but this appears not to have any effect what so ever lol. I mean, it gets passed into the VMX file actually, but it's like VMware simply ignores it.