Installing and Using Docker Toolbox for Mac OSX and Windows

Transcription

1 Installing and Using Docker Toolbox for Mac OSX and Windows One of the most compelling reasons to run Docker on your local machine is the speed at which you can deploy and build lab environments. As a huge fan of Vagrant, I love the ability to spin up environments such as the sandbox labs I ve been using for a long time with Vagrant and VirtualBox. Switching to Docker as an option for many of my quick labs has also meant the same ability to run as an abstraction on top of my laptop so that I don t end up in dependency hell with development libraries and underlying infrastructure needs that quickly begin to conflict as I do more testing and development. Installing Docker Toolbox on Mac OSX or Windows The best way to get started is to run the Docker Toolbox platform which deploys a Docker environment with popular and important Docker tools including: docker-engine docker-compose docker-machine Kitematic Navigate over to to get your appropriate version: Rather than document the steps on a continuously changing set of screens, I recommend that you follow the installation process with the tools you desire using the guides provided by Docker here: Once you re installed, you can kick the tires on Docker using your first Docker Hello World test container using the docker run hello-world command:

2 You can see that the container image was not local, so a download process started and then the container was launched. As long as you see the results like above, you re in business! We will be using this as a baseline for a lot of other examples in the blog. As usual, this is meant to emulate a basic Docker configuration and does not really reflect a multi-node deployment with overlay networking. The goal is to be able to quickly and easily launch containers using Docker Engine for a number of admin tasks that can replace what we may have been doing inside dedicated workstations or sandbox virtual machines in the past. Deploying a Docker Sandbox using Vagrant and VirtualBox Even with the addition of more client-side tools for running Docker, it still requires installing development tools that may impact your local environment. Plus, I m a fan of using VirtualBox to make sandbox environments that I can spin up and tear down as needed. This means that I never have to worry about version conflicts with development languages and dealing with package management on my Macbook or on my Windows machine. Every machine will use the same recipe. Deploying the VirtualBox Docker Sandbox Environment We are assuming you ve read the initial post, you have already installed Vagrant, VirtualBox and Git. Once you are up to that point and ready to go, we just need to pull down the code to deploy our Docker sandbox using git clone

3 first: Next, change directory into the folder cd virtualbox-docker-sandbox and then run the vagrant up command: That s going to run for a while, and you will see after about 10 minutes that you re back at the prompt. Now we can use vagrant ssh dockersandbox to get onto the console and confirm our environment: You ve got the nested instance running, and as you may have read in the build.sh file from the code we cloned, we have installed docker as well as docker-compose and docker-machine which will help us test the waters on a few different Docker features:

4 Now you can start up some Docker containers without having touched your local machine at all, and this ensures a clean sandbox deployment for you that is able to be quiesced using the vagrant suspend dockersandbox command: To bring the environment back up, just run a vagrant resume dockersandbox Running Docker as Sudo One thing to note is that we have deployed the Docker runtime as sudo, and because of that we must always run the Docker commands as sudo. This is a best practice in general, so when you try to run docker pull or any docker commands, you will see errors about the daemon not being available: Run the sudo docker pull nginx instead of docker pull nginx and you will see a marked difference in the results:

5 Happy Dockering! Run the AWS Shell Quickly and Easily in a VirtualBox Instance Using Vagrant Because we like the Martha Stewart pre-baked oven version of things, this is the shortcut to running the AWS CLI without having to dirty up your own local environment. Why use a Sandbox? While development entirely using your local machine is handy, there can often be configuration issues, and also conflicts with other development libraries. In my earlier post, you saw how to configure a basic sandbox environment. I m assuming that you ve already got the following installed as documented in that post: Git client Vagrant VirtualBox This is how to deploy and configure the AWS Shell environment using a sandbox server in just a couple of simple steps! Clone the GitHub Repo From your command line, you can just run a git clone to get ready with all the Vagrant code:

6 Next, we change into the directory and we run a vagrant status to confirm that the configuration is ready to run: We can see that it says not created for the machine, so let s run vagrant up and get this party started! Once the process is completed, you will see this message:

7 What s in the GitHub Repo to make AWS CLI work? The basic build of a sandbox machine was documented in my previous post, and the secret sauce for this is really quite easy. The only reason I like this approach is that I have a super simple deployment of a purpose-built machine to test out AWS CLI work. All with two simple statement: sudo apt-get install -y python-pip sudo pip install aws-shell Yes, it is just that easy. Once the machine completes the installation, you are ready to log in to the console and give it a try. We do this by running vagrant ssh awssandbox: Et voila! You are now ready to start up the AWS shell. Configuring and Running AWS Shell The environment is all installed. Now, we need to run our AWS shell which will do some basic configuration at the first launch: After the console comes up (it takes about 30 seconds to build the autocomplete cache), we have to configure it to use our AWS credentials.

8 When we start to type the configure command which you will see does an autocomplete: The three pieces of information you need to configure the AWS shell are your Access Key, your Secret Access Key, and the Region name you are working within. Just like with the web client, you have to choose a default region to explore. That can be changed again at any time by re-running the configure command: We are all set with our configuration, and you can start typing away on the AWS shell commands. There is an autocomplete function on everything, and you can even scroll up and down when the autocomplete suggestions come up: For example, we can list the regions by using the ec2 describe regions command that outputs a JSON response of the available regions:

9 We can also use the ec2 describe instances command to list out any active instances that are in this region under our account:

10 The output will span a couple of screens in a prompt window, but luckily we can scroll up or down and also copy the content out from the shell to evaluate in a text editor if you so desired. There are literally hundreds of commands, but the main thing we wanted to see here was how to just get the basic configuration up and running so that you can start exploring. To exit, you can use F10 or Ctrl-D to go back to the Linux shell prompt. Now you have your AWS shell environment ready to save and reuse as needed without having to deploy anything on your home environment. Another advantage is that you can snapshot this one, run it on any platform that supports VirtualBox, and not worry about versioning or anything at all with dependencies at the OS level.

11 Using Vagrant and VirtualBox to Run Sandbox Environments One of the things that I ve done lately is to ensure that I keep my laptop clean of any development tools. The reason is that I have run into a lot of problems with conflicts around versions, platforms, and general oddities that come as I deploy more and more different environments onto a single machine. Using Virtualbox and Vagrant for Sandboxes Luckily, using Vagrant and VirtualBox is both free and simple. I ve even saved some of the steps by storing basic configs on my GitHub to share and to let the community save some steps. Install VirtualBox Got to and you will see a nice shiny button on the main page to take you to the latest download, or you can also just got to to see the various versions. In my case, I m running Mac OSX, so I will choose the appropriate version. Once it is installed (just take the defaults) then you can run VirtualBox for the first time to complete the initial configuration. Install VirtualBox Guest Additions When you launch VirtualBox for the first time, it will prompt you to install the VirtualBox Guest Additions. This is some add-on features to correct problems on some Linux guests. Since we are going to be using lots of Linux guests, you should run the update. There is no other configuration needed for your VirtualBox because we are going to let Vagrant do all of the configuration from here on in. Install Vagrant Go to to get the latest and greatest Vagrant version, and install for your particular Operating System. There are no configuration steps required at all, so just take the defaults and you will be ready to go in a few minutes once the install wizard completes. Install Git Client If you are running OSX, just try to run Git from the command line and it will prompt you to install Xcode. Follow the steps and you will be Git-tastic in no time. Unfortunately, it does take a long time and download a lot of other stuff along with the Git client. For Windows and Linux folks, go to and pick out the version of choice to install.

12 Create your GitHub Repository For my instances, I use the naming structure virtualbox-productname-sandbox, so if I want to create one to do some nginx testing, I would call it virtualbox-nginx-sandbox as an example. Go to your GitHub account and create a new repository: You will want to do the following steps: Name the repo (virtualbox-nginx-sandbox in my case Set the repo as Public Initialize with a README Add the Apache License 2.0

13 Next, let s get the URL of the git repo to download and work with: Use your nifty git command line to clone the repository and then we can get started with creating the basic machine:

14 Make sure that you cd into your folder for the next steps to create the configuration files. Configure a Basic Machine My goto standard is usually an Ubuntu LTS instance. This has been the classic for many build environments, so I will just need to set up a very simple Vagrantfile to do this. The Vagrantfile file contents will look as follows: # -*- mode: ruby -*# vi: set ft=ruby : VAGRANTFILE_API_VERSION = "2" ENV['VAGRANT_DEFAULT_PROVIDER'] = 'virtualbox' Vagrant.configure(VAGRANTFILE_API_VERSION) do config config.vm.define mysandbox" do mysandbox mysandbox.vm.hostname = mysandbox" mysandbox.vm.box = "trusty-server" mysandbox.vm.box_url = " mysandbox.vm.provision :shell, :path => "build.sh" end end This basic configuration creates an Ubuntu machine named mysandbox and uses NAT networking on an internal network which will have access to the internet and your local network, but does not have a bridged NIC to connect back inside from external resources. You will see that it also calls a shell script named build.sh which is our configuration file to do the basic installs and any customized package deployments. For a basic machine, this is what the build.sh looks like: #!/bin/bash # build.sh Authors: Eric Wright (@DiscoPosse) export DEBIAN_FRONTEND=noninteractive echo "set grub-pc/install_devices /dev/sda" debconf-communicate sudo apt-get update && sudo apt-get upgrade -y

15 sudo apt-get install -y git vim openssh-server && sudo reboot We are setting the machine to run updates, a kernel upgrade to the latest revision, install a few packages, and then reboot. Configure your.gitignore The most important, but seemingly forgettable step is to create a.gitignore file which stops files from being ingested into a git repository. This is particularly helpful when you have downloads of base boxes, configuration files with passwords and other such local content you want to NOT go back up to the central repo. Here is my basic.gitignore file: *.box.vagrant/ The file is designed to not allow VirtualBox images to be captures, and it also protects the.vagrant folder which creates temporary SSH keys and other content that is mean to be volatile and instancespecific. Now you can simply do a git add to add your files, run a git commit to commit the changes, and finally a big old git push to push your changes up to the remote repository on GitHub. Running your Sandbox Instance It s as easy as vagrant up and once your instance is started, you can run vagrant ssh YOURHOSTNAME where YOURHOSTNAME is the name of the host from your Vagrantfile. Now you have a nifty little sandbox server to run all of your testing without having to much around with tons of configuration and local conflicts. WARNING: You have to remember that this is a sandbox instance and is not storing your changes anywhere except locally. Because you excluded the.box in our.gitignore file, the machine itself is not being backed up to the repository. You won t want to use GitHub to hold your sandbox servers, but you may want the internal code to be stored somewhere. For that reason, please make sure that back up any code you create or special files that need to be saved. Oops I need to Rebuild It s as easy as vagrant destroy and then running vagrant up and you are back up and running with your basic sandbox server. This is helpful when things go a little sideways and you need to go back to the beginning. You can also take snapshots within Virtualbox which I will put into another post soon. Happy sandboxing!