Licensing

VirtualBox is an open source virtualization platform owned by Oracle. It has been released under the GNU General Public License (GPL) Version 2 license. Full details of that license can be found at www.gnu.org/licenses/old-licenses/gpl-2.0.html .

If you wish to also use the VirtualBox Oracle VM VirtualBox Extension Pack you are required to agree to the terms of the VirtualBox Personal Use and Evaluation License (see www.virtualbox.org/wiki/VirtualBox_PUEL ). This license allows for personal or product evaluation or academic use only. If you intend to use this product in a commercial sense please abide by these licenses.

Creating a New VirtualBox Machine

Before we start our new VirtualBox machine, first make sure you have downloaded the appropriate ISO image file for CentOS 7. You can go to www.CentOS.org/download to fetch it. There are three options presented to you for download. The DVD ISO and Full ISO will take longer to download but will contain everything you will need for a desktop environment. If you choose the Minimal ISO your download will be quicker but you will have to download any extra packages (applications) from the Internet when you need them.

In this example we are installing CentOS from the following download link: http://isoredirect.CentOS.org/CentOS/7/isos/x86_64/CentOS-7-x86_64-Minimal-1511.iso .

The VirtualBox application runs like any other application on desktop. Find the application and start it. You will be presented with a screen similar to this one.

Figure 3-1. VirtualBox console

A new installation will not have any virtual machines installed. To create our own CentOS installation, we select the New button. In the window that comes up we will give the machine a name, Centos7 and we will select the Type and the Version of Linux and Red Hat (64 bit).

Figure 3-2. Naming and setting VirtualBox type

Next we can configure our memory size . This can be as large as your system allows. In general, 1024Mb is appropriate, or 512Mb for smaller systems without things like a graphic desktop. You can also adjust this after the install to match your needs. Use the slider or type in the amount of memory you need for your system.

Figure 3-3. Memory allocation

We are now asked if we wish to create a Hard disk. Here you can make a selection to use an existing disk or choose not to have a disk at all. We are going to click Create a virtual hard disk now and click Continue.

Figure 3-4. Choosing disk

There is a selection of the kind of virtual disk format we wish to choose next. VirtualBox gives us six options. We are going to select the default, VDI (VirtualBox Disk Image ) , and continue on.

Figure 3-5. Selecting Virtual Disk format

We can now choose if the disk is of a fixed size or if it will be dynamically allocated. Simply put, we can create a disk that will allocate the full size of disk we request or we can allocate only a small portion of that now, and as we need it, VirtualBox will allocate more of that space. The benefits of dynamic allocation are that you can overallocate your disk (meaning you can allocate more disk space to your virtual hosts than you actually have on your host). The downside is that there is a performance impact as VirtualBox allocates that space when it is required. Once the disk is allocated it cannot be deallocated back to free space in your virtual hosts. But because these virtual disks are just files on your host we can move them onto other storage devices or clean them up if we start running out of space on our host.

We are going to select Dynamically allocated and Continue.

Figure 3-6. Dynamically allocating disk

The default disk size is 8GB. We are going to select this and you can use the slider or type in the amount of disk you wish for your virtual host. Here you can also change the name and the location of the disk if you wished by selecting the little folder icon.

Figure 3-7. Disk amount

That creates the virtual host Centos7 .

Figure 3-8. Centos7 VM is almost ready

We can change the settings for our new virtual host or add more storage devices. We need to add a storage device to boot our operating system from. So we will select Settings and go to the storage tab. You can see we have an IDE controller that is Empty. We can click on the little DVD symbol and select Choose Optical Virtual Disk File. Navigate to the directory where you downloaded the ISO image previously. Select the CentOS-7 ISO.

Figure 3-9. Selecting image

The disk should now appear attached to the IDE controller.

Figure 3-10. Selected CentOS ISO is ready

We are now ready to install our operating system. Simply follow the steps in Chapter 2. An alternative way of getting a machine up and running quickly, however, is to use another tool, Vagrant. We will show you that in a moment, but first we want to show you Git (we actually really just want the terminal emulator but it doesn’t hurt to have Git working on your system).

Installing Git

One of the tools you will find very handy throughout your development and system administration tasks is Git. Git is a distributed version control system that is great at storing your changes to configuration files in distinct chunks of work, or commits. You can add a description to these commits so that people following you (and there are always people following you) can view the change you made and see a note that describes that change. You can also use Git to quickly see what has changed between different commits.

Downloading Git is very painless. You will either have it available to you as a standard package in most (if not all) Linux distributions or you can go to

http://git-scm.com/download .

We are going to demonstrate the installation on a Windows machine as that is less common than installing Git on Mac or Linux and has some options that might be difficult to understand.

Starting off, after downloading and opening the installer we are asked some questions. These might be new to some people. One of those is setting of the %PATH% variable in Windows. While these settings are up to you, we suggest the following:

In Figure 3-11 we are choosing the setting that allows us to use Git from the Windows Command Prompt and the Git Bash prompt. This gives us a bit of flexibility when working with our files.

Figure 3-11. Allow Git commands from the windows command line

The next step may take a bit of thinking as well. Now to confuse things, Windows and Linux systems (and even Macs) have different ways of telling a computer where the end of a line is in a file. In Linux the end of a line in a file is called LF (line feed ) and in Windows it is called CRLF (carriage return line feed ). So when you are making changes to files, the operating system will add the appropriate line end to the end of each line in the file. When you open this file on another operating system you get strange formatting in your editor. What we are doing here is taking control of what Git does when you commit this change. Git can control what these invisible line endings should be.

In Figure 3-12 we are allowing Git to convert LF to CRLF for Windows editing, but when we commit files we convert CRLF to LF again. With this option you should be able to interact with Git-controlled files without effort.

Figure 3-12. Allow Git to change LF to CRLF on checkout and CRLF to LF on commits

Next we configure which terminal emulator to use with Git. Git Bash is a good way to learn and to interact with Git. It has many Linux commands available to it as well as the Git commands. Of course, if you feel more comfortable with the Windows console feel free to select that.

Figure 3-13. Selecting the terminal

The next screen is not very important right now. You can add some experimental performance tweaks by selecting the check box you see in Figure 3-14. We are not going to select it but if you’re feeling adventurous you can.

Figure 3-14. Experimental performance options

Git Basics

Let’s quickly go through the common Git command you will need to know. The way that Git differs from centralized version control software is that it is decentralized! What that means is that each clone of the Git repository is equivalent to a “master” copy of the repository—including the history. This is the equivalent of each developer’s local copy also being a distributed backup of the repository. However most people use a centrally hosted Git repository service like GitLab, GitHub, or BitBucket and one of the first actions is to clone the repository:

$ git clone git@<githost.com>:<username>/git-repository.git

The foregoing command will log into the githost.com server using the SSH protocol (you can also use HTTPS, Git, or a local protocol). You gain access to the repository using your SSH public key for authentication on the githost.com server. Git will then make a copy of the git-repository.git repository on your local filesystem in a directory of the same name.

Once you have a copy of the repository you can begin to make your changes. One of the first steps is to create a branch. A branch is a set of discrete commits that all relate to a particular change. There is a main branch that is considered the main line or master branch (usually called master). Changes in branches are usually merged into the master branch. To make a new branch from the master branch you do this following command:

$ git branch my_change

You do this so that you can make contained and discrete branches of work in a named branch—and branches are cheap with Git (it is one of the selling points!).

You have now cloned, created a branch, and you have edited some files. You can use the following command to view the changes you have made to those files:

$ git diff

This command will show all the changes in the repository, you can add the directory or filename to the command line if you wish to narrow the scope of the diff. But let’s say you are happy with your diff and you are now ready to commit those changes.

$ git commit –v path/to/file/or/directory

You will be shown the diff of your changes again and you will be able to add a commit message to the commit so that people know what the change is. Good commit messages give some idea of what you did - preferably what was done and why it was done. Bad commit messages are “updated file.” You now have a commit in your branch and you might wish to merge that back into the master branch (you might not want to do this directly if you are working on a shared project—you may instead want to “push” your branch to the remote repository you cloned from and get others review it first). To merge back to master, issue the following commands:

$ git checkout master
$ git pull origin master
$ git merge my_change

What we are doing above is that we are first leaving our my_change branch and checking out the master branch—the master branch is normally the branch from which production code is taken from. We first do a “pull” on the origin (or the githost.com master repository) to pull in any other changes that have been checked in already. Then you merge your changes into the master repository and take care of any conflicts this causes. Once you are happy with the state of the repository you can “push” back to the origin (githost.com repository).

$ git push origin master

Your change is now able to be shared with anybody using that githost.com copy of the repository. This, of course, is a very simplified and potentially bad example. A workflow like above will no doubt lead to breaking things and you should have a way of testing code prior to merging to master. GitHub provides a good document on git workflows here: https://guides.github.com/introduction/flow/

For Windows users, now that you have Git installed you can use Git Bash to access useful Linux utilities like less, vi, grep, and tail. We will show you how we use Git Bash in the next section.

Introducing Vagrant

Vagrant is a way of sharing and distributing development environments between developers quickly and easily. In this sense a “development environment” is a set of virtual machines and a configuration for running those machines. Originally it was designed to manage VirtualBox machines via a combination of configuration files and command-line tools, but it has since expanded to be much more and supports other virtualization technologies. It was developed by Mitchell Hashimoto who then founded HashiCorp on the popularity of the product. It is written in Ruby and can run on any operating system that supports Ruby. Currently you can download and run it for Linux, Mac OSX, and Windows.

Installing Vagrant

You first can download it here for your operating system:

www.vagrantup.com/downloads.html .

Vagrant is meant to be driven by the command line; it provides no graphical user interface (GUI) . With Macs you can drive it all from a terminal window. On Windows machines you can run commands from the cmd.exe program, from PowerShell, or from Git Bash like we just installed.

Vagrant Concepts

The problem space that Vagrant tried to solve when it was originally developed was the sharing of virtualized machines and their configurations run under VirtualBox . Since that time it has expanded its support for virtualization technologies but its core tenant remains the same. It does this in two ways. It provides a mechanism for distributing and downloading other VirtualBox virtual machines as well as tools to manage the configuration and running of them.

Primarily Vagrant works with boxes. Boxes are just compressed files of pre-built VirtualBox virtual machines that have a few special things configured. They have a “vagrant” user that has access to root privileges and OpenSSH has been installed and is running. Vagrant uses VirtualBox commands (or VBoxManage commands) to create, configure, start, and stop these boxes—it does this with a combination of the VirtualBox CLI and SSH access via the vagrant user. You can download boxes from HashiCorp’s other service called Atlas or you can build your own. You can store, distribute, and publish boxes via Atlas too. Atlas has private and corporate offerings and integrations with other HashiCorp services.

You are not limited to using just VirtualBox machines either. You can run Amazon AWS or Openstack instances, LXC containers, and of course Docker containers. In this exercise we are going to show you how to work with a VirtualBox virtual machine. You are free to explore others at your leisure.

virtualbox/
total 1029016
drwxr-xr-x  6   dennismatotek  staff             204 12 Dec 16:44 .
drwxr-xr-x  3   dennismatotek  staff             102 12 Dec 16:44 ..
-rw-r--r--  1   dennismatotek  staff             505 12 Dec 16:44 Vagrantfile
-rw-------  1   dennismatotek  staff       526833152 12 Dec 16:44 box-disk1.vmdk
-rw-------  1   dennismatotek  staff           10589 12 Dec 16:44 box.ovf
-rw-r--r--  1   dennismatotek  staff              25 12 Dec 16:44 metadata.json

Getting Started with Vagrant

After installing, the first thing you will need to do is either open a terminal or get to a command prompt via cmd.exe, PowerShell prompt, or Git Bash prompt. Go to your favorite workspace and create a new directory or folder called first. Use the cd command to enter that new directory.

The output of the commands will be the same no matter which operating system you have. Issue the following command :

Listing 3-1. Vagrant Options

> vagrant
Usage: vagrant [options] <command> [<args>]

   -v, --version                    Print the version and exit.
   -h, --help                       Print this help.

Common commands:
    box             manages boxes: installation, removal, etc.
    connect         connect to a remotely shared Vagrant environment
    destroy         stops and deletes all traces of the vagrant machine
    global-status   outputs status Vagrant environments for this user
    halt            stops the vagrant machine
    help            shows the help for a subcommand
    init            initializes a new Vagrant environment by creating a Vagrantfile
    login           log in to HashiCorp's Atlas
    package         packages a running vagrant environment into a box
    plugin          manages plugins: install, uninstall, update, etc.
    port            displays information about guest port mappings
    powershell      connects to machine via powershell remoting
    provision       provisions the vagrant machine
    push            deploys code in this environment to a configured destination
    rdp             connects to machine via RDP
    reload          restarts vagrant machine, loads new Vagrantfile configuration
    resume          resume a suspended vagrant machine
    share           share your Vagrant environment with anyone in the world
    snapshot        manages snapshots: saving, restoring, etc.
    ssh             connects to machine via SSH
    ssh-config      outputs OpenSSH valid configuration to connect to the machine
    status          outputs status of the vagrant machine
    suspend         suspends the machine
    up              starts and provisions the vagrant environment
    vbguest
    version         prints current and latest Vagrant version

For help on any individual command run `vagrant COMMAND -h`

Additional subcommands                                                                                                       are available, but are either more advanced
or not commonly used. To see all subcommands, run the command
`vagrant list-commands`.

This shows you the full list of available subcommands to Vagrant. We are going to only show you four to get you started. The tasks we are planning to show you are

• initialize our first directory

• update the configuration file for Vagrant

• start our Vagrant Box

• check the status

• finally, SSH into the console

The first task we need to do is initialize our first directory. Issue the following command, vagrant initas shown in Listing 3-2.

Listing 3-2. Vagrant init

> vagrant init
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

The vagrant initcommand has simply placed a file inside your directory. This is the file that we use to configure our first Vagrant image. If we use the ls command to list the contents of our directory we will see the following (you may need to issue dir for Windows cmd.exe).

Listing 3-3. Showing the Vagrantfile

> ls
Vagrantfile

In Figure 3-3 we have one file called Vagrantfile and this file contains the configuration information used by the vagrant command to create our Vagrant hosts. If we look at the contents of that file it looks very much like Ruby code. That is because it is. This file uses Ruby code and Vagrant parses and loads this file when executing Vagrant commands. That means that you can use the Ruby language in the file to create lists, arrays, hashes, and so on. That becomes useful later on when working with more than one image in your Vagrantfile. Now open up the Vagrantfile with your editor. If you are using the Git Bash you can use the vi program. We explain a lot more about vi in Chapter 4.

The contents of the Vagrantfile looks similar to this shortened version shown in Listing 3-4.

Listing 3-4. Vagrantfile

Vagrant.configure(2) do |config|
 config.vm.box = "base"

 # config.vm.network "forwarded_port", guest: 80, host: 8080

 # config.vm.network "private_network", ip: "192.168.33.10"

 # config.vm.synced_folder "../data", "/vagrant_data"

 # config.vm.provider "virtualbox" do |vb|
 #   # Display the VirtualBox GUI when booting the machine
 #   vb.gui = true
 #
 #   # Customize the amount of memory on the VM:
 #   vb.memory = "1024"
 # end
end

In Listing 3-4 we have removed a lot of the comments and suggested settings. Without going too deep into the Ruby language here you may be able to see that we can write blocks of code between do and end statements. We pass the result of Vagrant.configure(2) to the config variable object. We can then use that to assign our Vagrant configuration. In Figure 3-4 we are setting config.vm.box to equal ”base.”

So let’s create a basic configuration for our first Vagrant image. First we can head over to the following link and see all the available boxes:

https://atlas.hashicorp.com/boxes/search

The Ubuntu team regularly pushes an official Vagrant box for public download. We shall use that as our Vagrant box. These Vagrant boxes are “base” images. You download them and use them as the basis for your own boxes. There are many available for you to explore.

In Listing 3-5 we are adding the ubuntu/xenial64 box. Vagrant will automatically download this from Atlas when we start our Vagrant host.

Listing 3-5. Vagrantfile—Adding aBox

Vagrant.configure(2) do |config|
 config.vm.box = "ubuntu/xenial64"
end

In Listing 3-5 we are setting the config.vm.box to ubuntu/xenial64.

Next we are going to show you how to configure a forwarded_port. A forwarded port allows a port connection from your host to the Vagrant host running inside VirtualBox . In this example we are connecting port 8080 on our host’s localhost address to the guest Vagrant host’s port of 80. This means if we are running a web server in our Vagrant guest machine, we can open our browser and point it to http://localhost:8080 and have a web server listening on port 80 on our vagrant host respond.

Listing 3-6. Vagrantfile—Adding Forwarded Ports

Vagrant.configure(2) do |config|
 config.vm.box = "ubuntu/xenial64"
 config.vm.network "forwarded_port", guest: 80, host: 8080
end

In Listing 3-6 you can see we are adding the forwarded port by setting the config.vm.network. We can also synchronize folders from our host to our guest hosts. This is invaluable when developing. By default, Vagrant will mount the current directory into the guest’s /vagrant directory. For the interest of this exercise, let’s mount the ./temp directory into the Vagrant user’s home directory on the guest.

Listing 3-7. Vagrantfile—Adding Synced Folder

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/xenial64"
  config.vm.network "forwarded_port", guest: 80, host: 8080
  config.vm.synced_folder "./temp", "/home/vagrant/temp"
end

Finally, we can configure the following. In this code group we are acting on the virtualbox provider. That is, the underlying virtualization platform that is running our box. At times it is useful to boot up your host and see what is happening on the console as it boots, especially when learning and debugging. The follow will enable the VirtualBox GUI and sets the memory for the guest to 1024Mb.

Listing 3-8. Vagrantfile—Adding Synced Folder

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/xenial64"
  config.vm.network "forwarded_port", guest: 80, host: 8080
  config.vm.synced_folder "./temp", "/home/vagrant/temp"
  config.vm.provider "virtualbox" do |vb|
    vb.gui = true
    vb.memory = "1024"
  end
end

Let’s save all that into our Vagrantfile and bring up our first Vagrant host. Issue the following command shown in Listing 3-9.

Listing 3-9. Issuing vagrant up

> vagrant up
vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:

vm:
* The host path of the shared folder is missing: ./temp

Oh look. In Listing 3-9 we have an error. Vagrant is here telling us that something went wrong with the “vm:* The host path of the shared folder is missing: ./temp”. Of course, we did not create the temp folder. Vagrant will parse the Vagrantfile and make sure everything in is in place before we start our machine. Go ahead and create the temp directory in the first directory and try the command again (mkdir temp).

Listing 3-10. Issuing Vagrant up

> vagrant up

During your first “up” you will see things as shown in Listing 3-11:

Listing 3-11. Vagrant up Output

==> default: Importing base box 'ubuntu/xenial64'...
==> default: Setting the name of the VM: first_default_1455714694375_15606
==> default: Clearing any previously set forwarded ports...
==> default: Fixed port collision for 22 => 2222. Now on port 2203.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 80 (guest) => 8080 (host) (adapter 1)
    default: 22 (guest) => 2203 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2203
    default: SSH username: vagrant
    default: SSH auth method: private key
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!

In Listing 3-11 we can see we are importing a base box (this one has already been downloaded, you might see the downloading step too). The name of the VM will be in the form of directory_box name_random numbers. You will be able to view this in your VirtualBox console (and change the settings just like any other VirtualBox). We can see the network is being set up including the ports we will use for SSH (22 => 2222). There is automatic port collision detection so instead of using port 2222, Vagrant chooses port 2203. The port forwarding for 80 => 8080 is next and then we wait for the machine to boot. When it does we create a set of SSH keys that we use to sign into the host. The public key of this key pair is injected into the machine. Finally we get the machine is booted and ready.

Listing 3-12. Final Steps of the vagrant up

==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
    default: /vagrant => /Users/dennismatotek/workspace/source/book/first
    default: /home/vagrant/temp => /Users/dennismatotek/workspace/source/book/first/temp

Once the machine is up we can then mount our directories. We have a default mount that mounts our first directory into /vagrant and we have our temp directory that we have mounted into /home/vagrant/temp.

Okay, now that our host is booted and ready let’s check its status with the command shown in Listing 3-13.

Listing 3-13. Vagrant Status

> vagrant status
Current machine states:

default                   running (virtualbox)

By default, our host name is default. You can name our machines different names in your Vagrantfile . In Listing 3-13 we can see ours is in the state of running.

Next let’s see if we can log into our Vagrant machine. To do that we issue the command shown in Listing 3-14.

Listing 3-14. SSH to the Vagrant Host

> vagrant ssh
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-35-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Wed Feb 17 13:11:35 UTC 2016

  System load:  0.77              Processes:           80
  Usage of /:   2.7% of 39.34GB   Users logged in:     0
  Memory usage: 12%               IP address for eth0: 10.0.2.15
  Swap usage:   0%

  Graph this data and manage this system at:
    https://landscape.canonical.com/

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

0 packages can be updated.
0 updates are security updates.

vagrant@vagrant-ubuntu-xenial-64:∼$

There at vagrant@vagrant-ubuntu-xenial-64:∼$ we have our command prompt of our Linux Ubuntu host. As you can see, it is a very simple way to build and run Linux servers. When you want to stop your Vagrant host, simply type exit to log out of the terminal session and then issue vagrant halt.

In Figure 3-15 we show the steps and output from our Git Bash terminal running on our Windows host.

Figure 3-15. Summary of actions