What is Reddit's opinion of
Vagrant?
From 3.5 billion Reddit comments
➔ Vagrant website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
> the only requirement is that a network card is Intel PRO/1000 MT Desktop (82540EM) and a mode is NAT
> [...]
> Until the patched VirtualBox build is out you can change the network card of your virtual machines to PCnet (either of two) or to Paravirtualized Network. If you can't, change the mode from NAT to another one. The former way is more secure.
edit: to change default with vagrant see: https://www.vagrantup.com/docs/virtualbox/networking.html#virtualbox-nic-type
I'm using a 13" non-retina MBP right now. I swapped out the mechanical drive for an SSD and installed 16GB of RAM and the thing's a webdev beast now.
EDIT: I'm surprised at the number of people installing servers directly on their Macs in this thread. Don't do that. Use a virtual machine - ideally with Vagrant and a provisioner so you can easily reproduce your dev environment. There are tons of pre-configured provisioner scripts out there for whatever sort of environment you'll be setting up if you don't want to spend time learning how to do it yourself.
Your dev environment should always be as close to your production environment as possible. Don't litter your dev machine with random versions of web servers, various databases, scripting languages, etc.
Docker complicates things more than you need right now.
I suggest using Vagrant (https://www.vagrantup.com/) for development environments instead of a central dev server, and writing Ansible, Chef, or Puppet code to provision both the Vagrant dev environments and the production server.
That way, dev and prod look very similar to each other.
This tool may help you get started with the provisioning part: http://phansible.com/
There are a number of disadvantages to installing your development environment locally. It's really easy to get yourself attached to certain versions of your tools (like PHP, Apache, etc) that can make it difficult if you need to bounce between different projects.
Vagrant is the most popular solution for running isolated development environments in Virtual Machines. Some docker-centric approach will probably replace Vagrant in the long term, but Vagrant is fine for most cases if you just want a small number of different environments.
If you go with vagrant, I'd highly recommend Laravel's Homestead box. Even if you don't use Laravel, this one comes prepackaged with composer, PHP7, mysql 5.7, Redis, and practically anything else you'd need for local development work.
Remote debugging is possible and isn't too difficult to setup. I wrote a gist for my team at work on how they can get remote debugging setup with Phpstorm and Homestead (or any Vagrant box). Maybe you'll find it useful too.
Well, Otto is being billed as the successor to Vagrant, so it might be worth understanding that first. Probably a lot of it carries over.
Vagrant is a tool that started out as a wrapper around:
- Virtual machine containers like VirtualBox or VMWare;
- Devops automation tools like Chef, Puppet or Ansible.
What Vagrant focuses on is building scripted development environments with these tools, which can be checked into version control and started up/torn down very easily.
So for example, for my current project we write and maintain Hadoop applications. On the top of our source tree we have a Vagrantfile that, when you run the vagrant up command, will fire up a tiny, three-machine cluster in VirtualBox, configure the VMs so they can talk to each other, install Linux and Hadoop, and mount the project's source tree in the VMs filesystem. So we can easily run the project's applications in a tiny Hadoop cluster to verify that they won't fail catastrophically. If we somehow mess up our environments we can just do vagrant destroy -f and vagrant up again to recreate them.
Reading through the Otto link, it seems like it's just an attempt by Vagrant's author to make a friendlier Vagrant.
OP, learn to use Vagrant ASAP. You stick a text file in each of your projects that says "Download this virtual machine, configure it this way and install such-and-such onto it". With one command it sets up a consistent VM to develop the project with. That way you can keep Arch as your base OS but use something stable for projects.
Check out vagrant, it will let you easily run and configure a VM with a web server as a guest on your host OS. You can sync the folder of the site you are working on, and even set your browser up to live reload the site as you are working on it.
https://bitbucket.org/wevansey/lampvm/
I use this set up as a good starting point for most projects, it is a vagrant box with the standard lamp stack and phpmyadmin set up and configured for you.
To avoid cluttering your machine with stuff for your dev environment, I’d recommend Vagrant (https://www.vagrantup.com). Plus, Vagrant is great for standardizing your workstation- someone on a different machine running a different OS can get their environment up and running really quickly if you’re using it right.
Plus, a lot of the VagrantFile concepts are similar to things like Dockerfiles, meaning it’s pretty simple to get your head around it all if you’re familiar with that stuff.
Use Vagrant to create a Virtual Machine for development. You can create one for each project and it will likely mimic the environment you will be deploying to.
https://gorails.com/guides/using-vagrant-for-rails-development
I can't say I've seen anyone willingly choose IIS for development when production is linux, no.
Vagrant makes it very easy to spin up a linux virtual machine that can mimic the production environment. You can keep using the same windows editors and browsers and share the code with the virtual machine using NFS (supported out the box with vagrant).
Check out Vagrant (https://www.vagrantup.com). If you're working with a different stacks its as good way to keep everything you install contained. Basically it let's you work on your Mac, but run your code in a virtual machine (a virtual server) so your local environment will better approximate your production environment (for example an Ubuntu server). It also keeps you from having to mess around with your Mac environment, which can be quite a bit different the a Linux system (that most of the web runs on).
Also look into Yeoman (http://yeoman.io) which is a great scaffolding tool when you're always setting up the same type of project. A simple command will get you up and running with all kinds of projects, from angularjs to just a simple HTML site with Bootstrap.
Some subs have automod post based on specific keywords. Maybe autopost the release documentation and some text on how the split with ansible-core, community package and galaxy works for someone asking about setting up 2.10+.
Basically a "hey, the versioning has changed for newer releases of Ansible, this is how it works"
And not specific to this sub in general, but I'd like fewer dead links on docs.ansible.com when I click through a URL from an external source. The site's layout got restructured but there's no redirects in place. I get greeted by the 404 as a lot of external documentation still points to the older site layout, like the Vagrant documentation.
Vagrant has a docker provider and a switch for forcing a vm. So all you need is this Vagrantfile:
Vagrant.configure("2") do |config| config.vm.provider "docker" do |d| d.build_dir = "." end end
and this command:
vagrant up --provider=docker --force_host_vm=true
to end up with a vbox image that runs the docker container inside it.
Note that this is also building the current Dockerfile in your directory and you can repeat the command on every change.
Edit: If you want something similar to docker, that is, in fact, not docker - then you should have a look at Vagrantfiles. They work similar to docker, but are for full blown vm's.
I use Ansible for deployment. I have a Vagrant virtual machine that's equivalent to the server, and provides an isolated, reproducible environment. So I use Ansible to deploy the code to that VM, and when it works, I just tell Ansible to deploy to the web server instead.
The way it works is pretty simple: I have a script that calls scp to copy the code over to the server. Then, the Ansible playbooks install SBCL and the other dependencies, set up Quicklisp, set up Nginx as a reverse proxy, that sort of stuff.
I use supervisor to run the processes. The supervisor job looks like this:
[program:my-app] command = /path/to/sbcl --eval '(setf sb-impl::default-external-format :utf-8)' \ --eval '(ql:quickload :my-app)' \ --eval '(lucerne:start my-app:app :port 8000)' user = {{ansible_ssh_user}} environment=HOME="/home/{{ansible_ssh_user}}",USER="{{ansible_ssh_user}}" autorestart = true
I used to use Linux as my primary OS, but I've since found that I really can't.
Sometimes I need software that isn't available for Linux.
Wine isn't complete enough to be a reliable way to run windows software when I do need said software.
I don't really use the features that Linux freedom offers, sure having a custom desktop environment is neat, but Windows and OS X don't have terrible UIs on their own.
Problems have come up more than once and the time spent on it was not worth the freedom of Linux.
OS X has shell scripting and bash like Linux does so the terminal isn't that much different since I'm not exactly a power user who needs to modify everything down to the kernel
I've had multiple driver issues.
I've had multiple issues that required a full reinstall more than once.
I've had issues getting my backups back, and when restoring from backup the program didn't inform me it wouldn't back up anything above my home directory.
Linux is a great idea and a useful tool, but it's not ready to be a primary OS, and until a company the size of Google makes a distribution and supports it the way MS does, it never will be in my opinion. Desktop environments are too unstable, the computer is too easy to break, and third party support is lack luster.
I still have Linux on my computer. I use virtualbox and vagrant to make little machines in my computer for when I need linux for whatever. It just can't be my primary OS.
You DO NOT want to switch to it on your desktop to CentOS
You DO want to keep some Vagrant VMs ( or Docker ) for all stuff related to testing packages, compiling etc.
From my experience do not clutter your workstation with stuff related to testing stuff to be deployed to servers
Also using CentOS desktop means you generally have outdated everything desktop related, no new and fancier nmap/wireshark etc.
When I moved from managing Debian servers to CentOS (changed job) I just deployed (having every server in Puppet is nice...) that:
alias apt-get='yum' alias aptitude='yum'
and that took care of 90% of mistakes I made.
Fedora might be fine, but Debian/Ubuntu have historically smoother upgrade process between releases
Pretty much all of the problems that you listed are issues that you'll have when working with most modern PHP frameworks and libraries.
As /u/warmans points out, you're making your life hard by using Windows. If you want to stick with Windows, I'd strongly suggest setting up a Linux virtual machine for your development (see https://www.vagrantup.com/). This'll make your life a lot easier, particularly with running programs from the command line and installing new development tools.
I'd advise that you spend the time and force yourself to get to grips with a modern framework such as Symphony and just accept that it will be painful at first. Once you get through the initial barrier you'll be opened up to a whole world of PHP that you didn't know existed.
On the framework note; I hate to sound like everyone else on this forum who blindly recommends Laravel for every project, but Laravel is a great framework with a smaller learning curve and good documentation, so that might be a better option than trying to jump straight into Symfony.
The Surface 3 is a bit under powered for your future programming classes, so you might hit a wall at some point. The Pro line is a bit more capable in that regard (I used to program exclusively on the Pro 2, for instance). That being said, the Surface 3 can still DO IT.
You're going to run into times where you wish for a more Linux environment for your future classes. In that regard, I highly suggest you look into
a) cmder - I have mine to cover one of my multiple screens when I press CTRL + ~ - full screen and transparent with multi tab. It's setup to be a MYSYS/Cygwin environment. It's not an actual linux environment, but it emulates a lot of common linux commands and emulates the pathing. Also makes a much better terminal experience.
b) vagrant - This is mandatory. You describe a VM for your project - what Linux you need, what programs you need installed, etc. It will download and install everything for you. then typing vagrant ssh in shell will headlessly connect your current folder and shell into that vagrnt box, giving you any linux OS running seamlessly in your windows terminal. SUPER useful for development.
Vagrant has a thing called Synced Folders. Its actually enabled by default for the main project folder. If you just need to move files between your Windows host and your Linux guest VMs this is how you do it. If you need other folders synced its as easy as editing the vagrantfile. The vagrantfile provided to you might already have all the synced folders you need already setup. Bonus: no network connections needed.
Your repository lacks instructions how to build/run your code, no distribution binaries too. Then at least put some screenshots or documentation. Plan, road-map or even a set of issues with milestones would be OK. Otherwise, newcomer needs to read all your code, to understand, where the code is, and then, blindly write the code for features (which is unlikely), if he does not know where to begin contributing. Existence of plan will help you too.
The best thing would be, if you would add fully functional vagrant system (virtual machine info files with bootstrap scripts, that installs and prepares all the required software, for test/build process of your software).
PS: Have you seen http://sourceforge.net/projects/spacetraderwin/ ?
Would need to be prerendered as it's a pretty slow process.
I set up the deepdream thingie for myself to play with but getting all the python dependencies sorted is a nightmare (at least on a windows machine)
So I recommend starting with this vagrant box instead:
https://github.com/aydindemircioglu/vagrantcaffe
It contains nearly everything required.
I only had to redirect parallel port to /dev/null.
In the meanwhile, trip on this: https://www.youtube.com/watch?v=oyxSerkkP4o
On Windows, there's MinGW and Cygwin but they're honestly just as much as a hassle.
The "true" other way is to use a Linux environment with a real package management system, or Mac OSX envrionment with Homebrew.
Or, use Vagrant to bundle a VM with your project so you don't need to install everything on your system. But that's only practical for certain kinds of projects, e.g. full-stack web development.
https://www.vagrantup.com/docs/providers/
You don't need to know virtualbox or vmware, vagrant will abstract it away. They recommend vmware though I always used virtualbox and never had any performance issues other than guest hardware limitations
I second the recommendation for Vagrant. I've been using it for local dev environments for the past few months, and it's insanely simple to use for getting a base VM up and running. Then you just provision it however else you find appropriate (I'm not familiar with Docker Swarm, but Ansible is a good route).
You can also pack everything together and make your own private base box that includes the general configuration of your software, which will reduce the ops team load as well.
/u/Kopachris has already covered the obvious thing here, but just so you know you can run most everything on macOS that you can on Linux. Furthermore, you can install something like Vagrant and get a linux VM running on your local machine.
I'm a django developer and all my machines run windows. What you are looking for is vagrant. It lets you run a headless virtual machine that has access to your project, and that you can ssh into. So all my editing is done in windows, and I use the command line in the VM for running django. If you have pycharm pro, it even has built in support for it.
Why don't you try running a Linux VM using virtualbox + vagrant.
You can run Windows and Linux at the same time. Deploy different variant VMs to see which one you like and experiment with different server configs, services, and environments then just easily destroy the ones you don't care for.
(EDIT) You can also share folders between Windows and the VM so you have access to your code from either OS.
> but recently one of my friends suggested that I partition my hard drive so I can use ubuntu as well
> Should I partition my computer?
virtualbox + vagrant = no reason to partition
> Is my current computer fine or should I go to the dark side with a macbook?
Read the FAQ.
You could setup a linux server in virtualbox or vmware. There's tons of vagrant configurations out there for node environments, and the files still live on your desktop PC so you can use whatever IDE you want.
I'm not Matthew, but I will note that a major piece of the Fedora 22 release was the inclusion of Vagrant, both the client-side pieces on Fedora Workstation as well as Fedora Cloud's minimal Vagrant image. This will make it very easy to produce repeatable development environments on Fedora.
check out https://www.vagrantup.com/
Keep your website in a bitbucket repo and youll be able to use any of your computers to develop. My 2010 macbook air can easily handle HTML, CSS, JavaScript, JQuery, MySQL. you really dont need a beefy computer for this 'basic' stuff. so as long as you're not treating your laptops as servers you'll be fine.
You should be able to use any of your computers for web development
If you're not taking advantage of IIS or some other Windows-only software, you should probably be doing one of the following: 1) dual-booting Linux for development or 2) running a Linux VM, because your hosting environment is probably Linux.
The dual-boot option gets you fully immersed in the Linux environment so you'll be better equipped for handling yourself in a Unix shell. Linux also has most every tool you need already in the package manager. Python development is easier on Linux than any other OS in my experience. A good starter distro is Linux Mint (either the Ubuntu or Debian-based version is fine). If your server happens to be yum-based/rpm-based, I'd look at the Fedora distro.
The benefit of a VM that you can stay in your already-comfortable environment while having access to a virtual version of your hosting environment. Most hosting seems to be on CentOS, Ubuntu server or Debian. The easiest, most integrated way to initiate this kind of setup is Vagrant
VirtualBox, while free, is garbage for performance. I was using it to test chef using vagrant (Seriously, if people are using virtual machines for testing, it behooves that developer to check out Vagrant.) and it was more than a factor of ten slower than VMWare Fusion.
If you really want to stay close to your lamp stack. Ubuntu as you main desktop isn't the way to go. Stick with Windows and use Vagrant to manage your projects. You get to stay on windows, but still use Ubuntu for your development work.
A straight switch over isn't the thing to do, and virtualization is easy, and all you really need when developing.
If you’re comfortable with the command line then you could use Vagrant. If you have Homebrew installed on your Mac then getting a Ubuntu 16.04 VM up and running with Vagrant is as easy as...
$ brew cask install vagrant $ vagrant init ubuntu/xenial64 $ vagrant up $ vagrant ssh
All being well, you should now be at the shell of a Ubuntu 16.04 host. From here you can then apt-get install gcc-c++ and whatever else you need. The folder you ran the above commands from on your Mac is mapped to /vagrant in the guest
With Vagrant you can create a cluster of VM's that can talk to each other [1]. If your database is ver big and you require to have a larger disk for you database VM then you can create that VM with a larger disk [2].
[1] https://www.vagrantup.com/docs/multi-machine/ [2] https://unix.stackexchange.com/questions/176687/set-storage-size-on-creation-of-vm-virtualbox
My advice: set up Vagrant and use a sync'd folder for Node development. Here's a gist setup of what I use. Then you can use your favorite editors and keep your workstation relatively clean.
Okay, let's clarify a little. You are trying to use Docker Machine to create a VM. Docker Machine is not Docker. Docker Machine is a tool to create VMs tailored to run Docker containers.
Are you planning on running a Varnish container or do you wish to SSH into the machine to install Varnish on the host?
Why do you require CentOS?
I have a hunch that you would be better served by a tool like Vagrant.
Vagrant is your friend in setting up VMs.
Here's a quick walk through. If you want to quickly get up and running with much of what you'll likely need, consider adding the Laravel Homestead vagrant box which has PHP7, MySQL, Nginx and much more already provisioned.
Use something like Vagrant + VirtualBox and provision a system that closely match your production environment. You will be able to "pre-deploy" / develop your application on that VM before going into production.
https://www.vagrantup.com/ https://www.virtualbox.org/
Your PHP 5.3 production system is probably Ubuntu 12.04 LTS ?
not really, with VM's you can run 4 different versions of Windows at the same time so if you have to support Windows 7, 8, 8.1, 10 it is actually possible to look exactly at that setup / test with that setup rather than Oh it should be this, this and that...
https://www.vagrantup.com/ is probably the most relevant project to what is mentioned above.
Here's the latest Homestead video tutorial, it's pretty straightforward: https://laracasts.com/lessons/say-hello-to-laravel-homestead-two
- Install Vagrant
- Install VirtualBox
- Add Laravel Homestead Vagrant Box:
vagrant box add laravel/homestead - Require Homestead globally
composer global require "laravel/homestead=~2.0" - Add homestead to your system environment
- Modify homestead.yaml as needed
homestead up
You don't have to tether yourself to a remote web server in order to run your app. Check out Vagrant. It allows you to set up virtual environments on your machine specific to your project.
Also if you are not yet using Git, learn it. I couldn't live in a world without version control. Highly recommended for all projects, even if you're not on a team.
If your intent is to just provide a local sandbox that you can generally recreate at-will, then this is a sufficient solution. Vagrant provides some good Ansible integrations (you'll want to decide if you're going to run it on your host system or in the VM). You should be able to start with a common Vagrant box like ubuntu/bionic64, and then add the Ansible playbook.
Vagrant is a really easy way to automate setting up a VM. You might find it convenient:
https://www.vagrantup.com/intro/getting-started/index.html
If you use an Ubuntu image, installing g++ is pretty much just sudo apt install g++
they do somewhat different things and are not mutually exclusive - in fact you might well use docker in two ways with vagrant - the docker provider to spin up lighter weight docker containers under vagrant-scripted control instead of heavier but better isolated virtual machines, and its docker provisioner for that matter.
Why not both? You can use Vagrant to quickly stand up virtual machines and have it automatically install docker on the system for you using the docker provisioner. The best part? You can save everything (notes, binaries, etc.) to GitHub (or your repository of choice).
Backend software development. I use vagrant to recreate my remote customer server environments. As an example, I have a customer that uses three boxes to deploy their web-app: an ubuntu box with nginx and separate boxes for their database and caching systems. I use Vagrant to recreate this setup on my Mac, so for just that one client I'll have 3 ubuntu server VM's live at once.
I also have services that I run for hobbies (price-checkers, a podcast feed duplicator, local git server). These services store their data on my NAS (mounted to the VM's through NFS). Eventually I'll push these to a dedicated box in my office. But for now they run as a lightly provisioned VM on my Mac.
The Mac Mini handles all this with aplomb. I have it hooked to a kill-a-watt right now and will post power-use statistics when I have enough data to be meaningful.
Think you should figure out what "end state" means for you first.
When you say "state of the current machine", what are you talking about? Running services? configuration files? custom configs? packages? What are the parts that were installed outside of base OS?
That script you listed seems to just check packages, doing what u/vinceskahan mentioned will be an easy way to get a package diff and you can just use like Vagrant with the Ansible provisioner to test bringing up a new install and adding the packages via tasks.
If you mean services like a LAMP or MEAN stack, then you will probably want to break things down into roles and tasks for the components instead of a single large playbook and break out variables so you reuse the roles for different machines or versions.
Some stuff, like personal custom configs (vim, tmux, git, bash) should just be thrown in a dotfiles repo and pulled down by Ansible, other stuff you may need to create templates for.
If you really want to clone the machine, you can do something like this even though it says ubuntu it's not really that specific, just do a sysprep then you can create a box for virtualbox/vagrant or run it in KVM.
Using Vbox or KVM will give you a closer clone to play with instead of trying to use docker.
In order from best to worst:
If the package is in testing or unstable I install it with
sudo apt-get install -t testing packagename, assuming I've already added those repositories to sources.list and set the Default Release.If there's a third party apt repository I add it to sources.list and add the required key. For example, here are instructions for mongodb. Since I store /etc/ files in a git repository, I can just clone the repository onto a new computer or after a reinstall.
If there's a deb package available for download I write a simple shell script to download and install it. For example, here's one for vagrant (to be run as root):
curl 'https://releases.hashicorp.com/vagrant/2.0.3/vagrant_2.0.3_x86_64.deb' | dpkg -i -It would be better if this verified the download with the checksum found here before installing, but it works.If it's available from source I write a script to download and install it. Something like this:
cd $(mktemp -d)
git clone [email protected]:user/repo
./configure
make
sudo make install
I keep all of the above scripts in a directory in a git repository, along with a simple script that just calls sudo apt-get install on my list of packages from the default repos.
Edit: how do I make a code block within a list? 4 spaces wasn't working
If you're just looking for VM environment for your project while working on your machine, you should check out Vagrant
If you really want to work inside the VM, I guess it should work, but I don't have any personal experience with that.
My recommendation is Vagrant which will let you replicate a virtualized server environment. It will run on Virtualbox, Hyper-V, Docker, VMWare, et al.
If you really can't accept the performance of a VM on your Surface Pro 3, then you're basically shit out of luck and will need to pay for a cloud-hosted solution.
Interesting post, but isn't it comparing unrelated things?
Isn't docker a little more like KVM or somthing - it is a low level tool for managing instances. Whereas Vagrant is a bit more high level, more like docker-compose.
Vagrant can actually use docker even: https://www.vagrantup.com/docs/provisioning/docker.html
I'll try.
First off, I want to be clear, I'm not preferring vagrant in any way over docker. I simply haven't learned docker yet, and I thought there might be other potential developers out there who still use vagrant in their development workflow. (I'm not a developer, I'm an IT generalist.) My guess would be the core devs use docker and docker compose.
The short version is, vagrant is a way to share and manage isolated and consistent environments between developers where the code is expected to work. Generally, this is done by sharing virtual machines, although it does support docker containers these days.
Here is a more detailed explanation: https://www.vagrantup.com/docs/why-vagrant/
If you want an explanation of how vagrant compares to docker, the authors of each tool probably explain it best:
What? I mean, use Packer to build your own base box and cloud images, and use them as a starting point for your automation scripts.
So your process becomes:
Run packer to:
- Build a Vagrant base box
- Build cloud images
When developing your automation:
- Use vagrant to pull your custom base box
- Apply your configuration using your favorite automation tool
- Modify automation and repeat until you have someone you're happy with
- Commit automation to source control
In production:
- Use your cloud tooling to spin up a new host
- Apply your configuration using the automation you developed earlier
- ???
- Profit
Local / Development:
I like virtual machines. You can use something like Vagrant. Sometimes you can even find them off-the-shelf. Or you can install VirtualBox and do a full Linux install and put all the components in place yourself.
Production:
Be careful. Personally, I would never do it. And I manage three servers at work. Why? Because I can spin you up a dev server in my sleep. But I don't know the first thing about proper standards, security, or anything else that you need in production. If you're doing it for a client take the money and then use a managed hosting service. It will most likely not be worth the money to manage it for them.
Look up Vagrant (https://www.vagrantup.com), it's made specifically for this purpose! It's not online but it's a virtualization software that makes it easier to have the exact same dev environment on different machines.
> So are you using Docker as a development tool or just as deployment one?
Docker is a deployment tool. Trying to use it as part of your development workflow, especially if you're using old-school Java tools like Eclipse and Maven, will lead to headaches.
If you want something to simplify / standardize your development environment, Vagrant is probably a better option.
edit: should have known better than to post "a screwdriver isn't the best tool for hammering nails" to /r/screwdrivers...
I understand Docker, and use it everyday at work. However, OP is trying to install Maven into the container, then (presumably) copy Java source code in, and run the maven compile inside the container. This breaks many of the Docker best practices, like having containers be immutable, and having a container image be something that can be deployed as-is to a staging or prod environment.
It's much better to have your build system (such as Maven, Gradle, or sbt) sit alongside the Docker engine. The build system does the compilation & unit testing then outputs a JAR or WAR. If your build system supports it, it can also build a Docker image for you, but if not, you can just write a Dockerfile that includes "COPY output/foo.jar /srv/whatever". For the concerns OP mentioned (like having IDE run configurations, or being able to right-click > debug instead of setting up a remote debugger session) Docker doesn't need to be in the picture.
On a team that wants to standardize their environment setup (which version of Maven, Docker, and other tools are installed) Vagrant is a useful way to do that. And note that Vagrant and Docker aren't in competition - you end up running your Docker containers inside a Vagrant VM.
Set up Vagrant on your MacBookPro. It uses Virtual Box behind the scenes to set up a development environment, and it integrates with Chef, Puppet, Ansible, or Salt for configuration management.
https://www.vagrantup.com/docs/getting-started/
It will allow you to work with common DevOps tools without requiring spending money on AWS instances. That way you can use the free tier to learn about AWS services, and still have the freedom to set up as many development instances as your hardware can handle without spending any more money.
They aren't the same and aren't meant to be. Vagrant is a high level tool to wrap provisioning tools and 'providers' like VMs and containers; effectively hiding the implementation details of your local env behind the command 'vagrant up'. Docker, docker-compose, and vagrant work together well and there's even and official provider for it: https://www.vagrantup.com/docs/docker/ and a third party module for docker compose.
I already had Vagrant and VirtualBox installed on my Windows environment, so I skipped to Step 0, although I'll note you are using an old version of Vagrant.
> Now, run vagrant global-status and you'll see that it prints out something like
While this is a handy command, I might lean toward waiting on this just to keep things simple.
> Go to the directory you used git to download in the last step [...]
I think you could be more specific about the directory here. Possibly even showing the command line with the directory prompt.
> [...] use your favorite text editor to open the file with the name Vagrantfile
Instead of manually creating the vagrantfile manually, use vagrant init command. It is less prone to error and with the minimal flag, it doesn't give you any of the comments or examples.
vagrant init ubuntu/trusty64 --minimal > Step 2: Running Multiple Machines on Vagrant
I think you are jumping into the deep in here. I think you'd be better off to start with vagrant's salt provisioning and split to multiple machines later.
The nice thing about splitting later is, if you setup your salt top.sls file to look like:
base: '*': - os-users - db - webportal
Then you can split to multiple machines by simply adding the extra machine name to Vagrant file and then changing the top.sls to something like the following:
base: '': - os-users 'db': - db 'web*': - webportal 'dev*': - db - webportal
> Step 3 > [...] > vagrant ssh
One of the benefits of automating things with salt and vagrant is that you don't need to manually install anything. In fact, I'd say you shouldn't manually install anything.
edit: cleanup formatting
If you've never used virtual machines, it'll take a little reading to fully understand what's going on, but Vagrant is what you're looking for. Installing Vagrant essentially runs a VM in the background allowing you to develop on the exact same environment from any machine.
When you setup your Vagrant settings, you pick a "box", (basically a server config). I'd recommend ScotchBox which is a pre-configured LAMP setup and should have everything you need.
And if you're not already doing so, get your projects version-controlled with Git so that way you can push and pull your projects from any machine and not carrying around those on a flash drive. :)
I highly recommend using Vagrant. It basically manages your Virtualbox instance for you via a simple config file that you place in your current project's main directory. I'm using it now in Windows 10 without issue.
If you're afraid to mess anything up on your computer, consider using Vagrant and Virtual Box to develop using a virtual machine that will more closely resemble your production environment.
Otherwise, try using WAMP, which I find simpler than XAMPP.
Edit: It looks like you went with XAMPP. that'll do fine.
>I've even read suggestions that I should be using Linux, which I'm also unfamiliar with.
All the more reason to use it, if you ask me :). If you're looking to get hired as a PHP dev, having LAMP experience can be beneficial.
It's not as hard as you may think to get a simple environment setup...you can find some decent tutorials online which walk you through the process too (https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu).
Also, have you heard of Vagrant? Worth considering IMO (https://www.vagrantup.com/downloads.html)
Agreed. Also if you're deploying to a Linux box it's a good idea to test on one as well, not to mention you'll save time not having to learn how to configure things in both environments.
Vagrant is an absolute life saver for this sort of thing if you're forced to work on Windows.
Huh, looks like your ad is still working, 5 months later!
It's proving a great read so far, even for newbie like me :D
A couple of questions: any chance of you making a copy/pasteable version of your Pregame available on your site? Some of those URLs are long, and I'm lazy. Alternatively, any objections to me pirating a digital copy of your book for this purpose?
Also, would it be useful to have a Vagrant distribution of your setup? Means that anyone would be able to pull down a saved version like you suggest. It's probably how I'll save my backup copy, but I'll leave it up to you whether I make it publicly available. It's your suite of tools, so your call :)
Awesome work once more on the book - looking forward to becoming much more competent at offence!
Yes, rails on windows kinda sucks :( you might want to look into something like vagrant, allowing you to work on windows like you're used to, but running your app in a headless Linux instance.
Since you're thinking about going that route, might I suggest Vagrant? It automates creating and provisioning VMs, and it integrates very well with PyCharm (you can use the Python install in a virtual machine as the project interpreter in PyCharm). It's pretty nice being able to develop in an environment that more closely resembles your production environment, too.
I found Ansible's official documentation (http://docs.ansible.com/intro.html) to be pretty good for starting out with it. Puppet was more of a trial by fire in my case, so I'm not sure where the best info on it is located. Either way though, I'd suggest using vagrant (https://www.vagrantup.com/) if you haven't already heard of it. It will let you set up virtualbox machines and deploy to them using various provisioners (including ansible, puppet, and salt). That way you can set up some simple mock machines using each and see which one you like best.
Getting a decent Rails environment up and running under Windows is absolutely excruciating. You're not going to be running Rails in production under Windows (unless you're insane), so there's no reason to do it in development.
One option to definitely look at is Vagrant. Most of my team used this until they all eventually just switched to OS X.
I'd recommend using a virtual machine using Vagrant rather than trying to setup the environment on Windows itself, and that way you'll have a proper terminal in the virtual machine
We use a Vagrantfile from https://puphpet.com/ which is a site that helps you configure and create your Virtual Machine with all the extensions and modules that you need
Id love to see more stuff like Vagrant ( https://www.vagrantup.com/) on the show. I recently discovered Panamax (http://panamax.io/)
These are awesome utilities that rival or utalize docker.
Id love to see users suggest linux blogs other then phronix, or linux insider. Nothing wrong with those blogs, but linux is about more then the biggest and brightest star in the sky.
KDE and Gnome are great, Arch and ubuntu are cool too, but there is only so much offshoot from that same old stick you can talk about.
I love the show, i can honestly say ive been listening for years, but there is so much more stuff that could be covered.
Yes, i understand its just a couple guys n gals working your butts off, working for sponsers and donations. How about a show for non noobs? A show that assumes we know what we are doing and to push us further then a basic os.
Like have Matt build LFS, build a cloud of vagrant images for us to pull down, host a public github for coder radio or something for us to play with. Idk, im kind of rambling i know.
My point is you guys have the crowd now, lets take this up a notch, and or out a notch.
Make a separate VM for each project. Use vagrant or chef to automate provision those VMs. This approach has two primary benefits: 1. isolates the dependencies for any project you work on and them from interfering with each other. 2. Reproducible environments. The description files for those environments can be committed to your version control system.
He mentions boot2docker as the way to use docker on osx, but vagrant has supported docker since 1.6. I'm told it's the better way to go these days. https://www.vagrantup.com/blog/vagrant-1-6.html#features
Use before and after properties to define order of provisioning blocks.
https://www.vagrantup.com/docs/provisioning/basic\_usage
Edit: It's an experimental feature, is there any reason you can't fetch from your host to your guest? Doesn't Vagrant also sync a shared folder?
> I have a script I've used to deploy one but it would be more convenient as a docker image.
No, imo, look up vagrant. Vagrant is a tool that predates docker for making VM usage dead simple.
Not sure about your use case, but if this is just for a personal openbsd vm, a possible alternative would be to use Vagrant on your linux host as it supports NFS shared folders.
If you're on windows, you could use vagrant's SMB synced folders instead, combined with something like usmb or smbclient in openbsd to access them from openbsd.
In the past when this happend, the VM was waiting for something on the console... so ssh isn't being started.
In the Vagrant file try turning on the GUI:
https://www.vagrantup.com/docs/providers/virtualbox/configuration.html
I would have made one box of each type and then include one of each in the vagrantfile for the environment.
Thanks for the explaination and a solution!
What I was trying to accomplish was nothing more than just testing whether I have correctly assigned the variables to their respective scope and also whether the unassigning was also successful. I wanted to do this because I wanted to set different persistent values for the environment variable VAGRANT_HOME values respective to the user that's currently logged into my machine when using Vagrant on an external ssd drive.
I also needed to be able to remove these variables but I wasn't sure if I was doing it right. The only way I've found so far to remove variables from a scope is by setting $null to those values.
Here is the code I'm using to 'unassign' or 'unset' my scoped environment variables
[System.Environment]::SetEnvironmentVariable('myUserVar', $null, [System.EnvironmentVariableTarget]::User) [System.Environment]::SetEnvironmentVariable('myMachvar', $null, [System.EnvironmentVariableTarget]::Machine)
Is this the only way (or even the correct way)?
From here:
> -c COMMAND or --command COMMAND - This executes a single SSH command, prints out the stdout and stderr, and exits.
So it's vagrant ssh -c /bin/sh.
vagrant is a simple VM management tool/later that lives above your VMM (VirtualBox, VMWare, etc). https://www.vagrantup.com/
makes it easy to get boxes, provision them, manage them, etc. once you use it it's hard to ever go back to bespoke, hand built VMs or clunky VM management interfaces again. Vagrantfile FTW.
once you have vagrant installed this is how easy it is to install a Kali VM: https://app.vagrantup.com/Sliim/boxes/kali-linux-2.0-amd64
Hi, I did end up pursuing this, I just wanted to post that this video:
https://www.youtube.com/watch?v=PmOMc4zfCSw
was hugely helpful and got me up and running in minutes. am just leaving this here in case anyone stumbles across this post and finds it helpful. Your notes are helpful too, particularly for stopping the machine.
This link was also helpful for teardown:
https://www.vagrantup.com/intro/getting-started/teardown.html
If you need fast way to set it up:
- Install Vagrant
- VirtualBox (and VirtualBox Extension pack)
- In terminal type:
vagrant init jhcook/macos-sierra; vagrant up
I tend to use Vagrant or Docker to give predictable and reproducible environments tuned to each project regardless of their stack. Local setups tend to be more flaky, hard to reset from scratch, or hard to tune to different applications at once and much less portable between different developers - they end up with the it works for me type of problems.
What is the type of content that you are needing to use in the VM? Could you just put it in a synced folder (https://www.vagrantup.com/docs/synced-folders/) and keep the actual git repo and process located on your host machine?
You could use the AWS free tier if you need cloud hosted stuff to play with.
If you've got a decent system you could use Vagrant to manage VirtualBox and run almost all of the boxes on the Vagrant box repository
No problem.
Yes i would recommend just keeping everything in the Repo, that way you can easily access the code anywhere you may need.
Not sure what VM setup you are using, but if you dont already know about it, take a look at https://www.vagrantup.com/. Nice way of managing your VMs.
Hope that helps!
+ Vagrant if you want as close to the whole "remote logging in" experience as you can get locally. Setting it up may be a bit tricky at first (iirc, Vagrant doesn't play well with virtualbox over v5.0.18.) but once its set up, installing a simple Ubuntu box and going by Digital Oceans tutorials on setting up a basic web server and securing it are pretty solid.
In my old job (~2009 - 2015), the only supported client OS was Windows. While our client management did a really great job keeping our laptops running, we were limited to using SecureCRT as a terminal emulator. Furthermore, braindead security policies forbade us from either generating SSH keys on one of our Linux servers or using SSH Agent Forwarding, so I couldn't really use a "native environment". I ended up relying on Cygwin, and while it's great software, the performance sucked and more complex operations (especially large git rebase/merge/...) often crashed. Furthermore, we weren't allowed to run VMs locally, so no Vagrant for me (and no, we couldn't use other hypervisors). The others and I managed to get things done, but in hindsight, we could have been a lot more effective.
(Funny story: The whole Linux team, including me, quit between October 2015 and January 2016 - mainly for other reasons, but the feeling that our work was unnecessary complex was a reason that contributed to our decision).
At my current job, I started with Fedora (our servers are mainly CentOS, with a few Oracle/RHEL installations mixed in): Exchange provides EWS, and support for that is reasonably reliable. If I ever need access to office products, I can connect to a Windows 10 VM - I did indeed make use of this once or twice until now. Generally, I'm a lot more effective now. At the beginning of September, after finishing a major project, I took two days to replace the Fedora on my workstation with Arch Linux (which, together with Debian, I feel a lot more comfortable using), running LVM on top of full system encryption. I also, erm, "requisitioned" (much love to my ops team!) an old, rotating hard disk to run regular rsnapshot backups.
OP, you're taking on a lot at once. a good grounding in linux before you start trying to drive a thing is useful. Learn a bit of linux first (RHCSA track is very good).
if you are serious about learning linux and ansible, then
would get you trained with videos AND cloud servers you can freely spin up and break for a fraction of the cost and time it would take you to build this stuff yourself.
as you seem to be new to linux, then on your windows workstation which you likely have
install WSL (ubuntu on windows basically) install virtualbox create some VMs.
for bonus points get vagrant going with WSL https://www.vagrantup.com/docs/other/wsl.html
put Alpha and Bravo each in their own network, and put a third box Charlie in both networks. You can do that with 1 Vagrantfile
On box C you can then do all the firewall things you want. You can use the tc command on C to simulate network problems. Google 'linux tc simulate network problems' for more.
What you're looking for is Vagrant.
Orchestrate the automatic creation of any number of VM's, set their parameters, run provisioning scripts to get what you need installed on them, presto. I use it in development as a way to simulate multiple remote data storage systems.
Ah, ok. Context is important. Depending on resources available, and your linux admin experience, I'd probably second the VM recommendation. Perhaps a tool like Vagrant would be better suited to your purposes, enabling you to start and run multiple VMs locally. Looks like Vagrant supports docker as well, though I unfortunately can offer you no guidance there... (but if it's like any other provisioners, it'll be well documented and easy to use). Otherwise, for building and running containers, (even Docker containers), I think Habitat is the way to go. (personally, I find Habitat much more straightforward for building and running containers) You can run Kube locally, though I'm not sure if there's any real advantage to that than just a big for i in {1..100}; do docker run -d --name foo${i} hello-world; done.
If you're already familiar with Docker or LXC, I'd say you should use that, since your thesis really isn't about the VM/Container technology.
IMO: stay away from swarm. I know people who swear by it, but my experience has been anything but positive.
Is 10k routing entries a lot? What kind of memory do you expect to be consumed?
And totally understand, if there is anything you can share love to hear about it, but I totally understand if you can't share anything too.
Good luck!
As jldugger mentioned, kitchen is a handy tool for streamlining this. Sometimes, you don't want/need that extra layer in your process. In this case, I would suggest using the chef-solo provisioner for Vagrant. You can put everything into your vagrant directory ( I typically place it into a sub directory aptly named 'chef') and include it as part of the Vagrantfile. Take a look at the documentation from Vagrant on how to configure. (https://www.vagrantup.com/docs/provisioning/chef_solo.html)
The configuration will prevent the extra steps of running solo or client from within the host as the link you shared mentions. If you are building and testing cookbooks specifically, then definitely checkout Test-Kitchen as it will make life easier with multiple converge and testing phases.