From 16c4cc7dd6822a8ef802979b87dc71c14f88fb51 Mon Sep 17 00:00:00 2001 From: MjSeven <33125422+MjSeven@users.noreply.github.com> Date: Sat, 14 Apr 2018 17:39:17 +0800 Subject: [PATCH 1/2] Delete 20180405 Getting started with Vagrant.md --- .../20180405 Getting started with Vagrant.md | 167 ------------------ 1 file changed, 167 deletions(-) delete mode 100644 sources/tech/20180405 Getting started with Vagrant.md diff --git a/sources/tech/20180405 Getting started with Vagrant.md b/sources/tech/20180405 Getting started with Vagrant.md deleted file mode 100644 index 71589f3e40..0000000000 --- a/sources/tech/20180405 Getting started with Vagrant.md +++ /dev/null @@ -1,167 +0,0 @@ -Translating by MjSeven - - -Getting started with Vagrant -====== - -![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/containers_scale_performance.jpg?itok=R7jyMeQf) -If you're like me, you probably have a "sandbox" somewhere, a place where you hack on whatever projects you're working on. Over time, the sandbox will get crufty and cluttered with bits and pieces of ideas, toolchain elements, code modules you aren't using, and other stuff you don't need. When you finish something, this can complicate your deployment, because you may be unsure of the actual dependencies of your project—you've had some tool in your sandbox for so long that you forget it must be installed. You need a clean environment, with all your dependencies in one place, to make things easier later. - -Or maybe you're in DevOps, and the developers you serve hand you code with muddy dependencies, and it makes testing that much harder. You need a way to have a clean box to pull in the code and run it through its paces. You want these environments to be disposable and repeatable. - -Enter [Vagrant][1]. Created by HashiCorp under the [MIT License][2], Vagrant acts as a wrapper and frontend for VirtualBox, Microsoft Hyper-V, or Docker containers, and it is extensible with plugins for [a great many other providers][3]. You can configure Vagrant to provide repeatably clean environments with needed infrastructure already installed. The configuration script is portable, so if your repository and Vagrant configuration script are on cloud-based storage, you can spin up and work on multiple machines with just a few limitations. Let's take a look. - -### Installation - -For this installation, I'm working on my Linux Mint desktop, version 18.3 Cinnamon 64-bit. Installation is very similar on most other Debian-derived systems, and there are similar installers for RPM-based systems on most distributions. Vagrant's [installation page][4] provides downloads for Debian, Windows, CentOS, MacOS, and Arch Linux, but I found it in my package manager, so I'll install that. - -The easiest install uses VirtualBox for the virtualization provider, so I'll need to install that, as well. -``` -sudo apt-get install virtualbox vagrant - -``` - -The installer will pick up the dependencies—mostly Ruby stuff—and install them. - -### Setting up a project - -Before setting up your project, you'll need to know a bit about the environment where you want to run it. You can find a whole bunch of preconfigured boxes for many virtualization providers at the [Vagrant Boxes repository][5]. Many will be pre-configured with some core infrastructure you might need, like PHP, MySQL, and Apache, but for this test, I'm going to install a bare Debian 8 64-bit "Jessie" box and manually install a few things, just so you can see how. -``` -mkdir ~/myproject - -cd ~/myproject - -vagrant init debian/contrib-jessie64 - -vagrant up - -``` - -The last command will fetch or update the VirtualBox image from the library, as needed, then pull the starter, and you'll have a running box on your system! The next time you start the box, it won't take as long, unless the image has been updated in the repository. - -To access the box, just enter `vagrant ssh`. You'll be dropped into a fully functional SSH session on the virtual machine. You'll be user `vagrant`, but you're a member of the `sudo` group, so you can change to root and do whatever you want from here. - -You'll see a directory named `/vagrant` on the box. Be careful with this directory, as it'll be synced with the `~/myproject` folder on the host machine. Touch a file in `/vagrant` on the virtual machine, and it's immediately copied out to the host, and vice versa. Be aware that some boxes do not have the VirtualBox guest additions installed, so the copy works only one-way and only at boot time! There are some command-line tools for manual syncing, which might be a really useful feature in a testing environment. I tend to stick to boxes that have the additions in place, so this directory syncing just works without me having to think about it. - -The benefits of this scheme become quickly apparent: If you have a code-editing toolchain on the host and don't want it on the virtual machine for any reason, that's not a problem—edit on the host, and the VM sees the change at once. Make a quick change on the VM, and it's synced to the "official" copy on the host, as well. - -Let's shut the box down so we can provision some things we'll need on this box: `vagrant halt`. - -### Installing additional software on the VM, consistently - -For this example, I'm going to work on a project using [Apache][6], [PostgreSQL][7], and the [Dancer][8] web framework for Perl. I'll modify the Vagrant configuration script so that the things I need are already installed. Just to make things easy to keep it updated later, I'll create a script at the top of `~/myproject/Vagrantfile`: -``` -$provision_script = <