Thank you, Alan, for the further explanation. These are, definitely, important 
distinctions.

I appreciate your support, Code4Lib community!

-----Original Message-----
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Harnum, 
Alan
Sent: Friday, April 08, 2016 9:11 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Islandora & Vagrant - Development use only?

While I can’t comment on the Islandora piece, I’ll make the following comments 
about Vagrant in the context of how we use it as part of our development and 
ops process:

- Vagrant is used as described below for “disposable environments and 
consistent workflow” for testing our automation scripts and tools - we use 
fairly barebones Vagrantfiles to bring up VMs that match our production 
environment targets, then provision those with the same Ansible playbook 
intended to be used in production. This lets us rapidly develop and test our 
automation before turning it loose on an environment outside our local machines

- production servers are also virtual machines, using KVM on Red Hat; these get 
provisioned with the same Ansible playbooks developed initially using Vagrant. 
There’s nothing inherently unsound about the idea of running using virtual 
machines in production, provided you understand the reasons behind and accept 
the overhead of doing so (in our case, our production VMs are launched and 
managed on a large, dedicated cluster intended for virtualization)

- it’s possible the idea is to use Vagrant as a virtual machine management 
solution in production; I agree with others below that this isn’t an optimal 
solution, nor I think would Vagrant’s creators (I personally Hashicorp has 
blurred the lines on this in recent years as they try to extend their business 
model, which may be where some of this is coming from)

- if the position is that Vagrant is the same class of environment isolation 
tool as RVM or virtualenv, that’s a misunderstanding; RVM or virtualenv create 
isolated environments with very little overhead running on the same system, 
while Vagrant creates virtual machines with all the overhead that entails

ALAN HARNUM
SENIOR INCLUSIVE DEVELOPER
INCLUSIVE DESIGN RESEARCH CENTRE, OCAD UNIVERSITY

E ahar...@ocadu.ca<mailto://ahar...@ocadu.ca>

On Apr 7, 2016, at 1:56 PM, Annamarie C Klose 
<ackl...@frostburg.edu<mailto:ackl...@frostburg.edu>> wrote:

Thank you to everyone who provided feedback on this issue. I've posted my 
question to the Islandora Google group, as well. I'll be meeting with my 
university's IT department on Monday. I appreciate your help!

Anna

-----Original Message-----
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Cindi 
Blyberg
Sent: Wednesday, April 06, 2016 5:46 PM
To: CODE4LIB@LISTSERV.ND.EDU<mailto:CODE4LIB@listserv.nd.edu>
Subject: Re: [CODE4LIB] Islandora & Vagrant - Development use only?

Cary, the snippet to your email as shown in my inbox only showed the first 
sentence. Glad to read the rest! :)

On Wed, Apr 6, 2016 at 2:01 PM, Cary Gordon 
<listu...@chillco.com<mailto:listu...@chillco.com>> wrote:

I disagree with the statement that "Vagrant is not a good idea for production.” 
Vagrant is a terrible idea for production, and it is not designed for that.

We use Ansible to build Islandora, and, after three years of talking about it 
we are starting to use it with Docker. We are an AWS shop, so we use Docker 
with AWS elastic container service, which could come in handy if one of your 
archives gets slashdotted.

Cary

On Apr 6, 2016, at 8:53 AM, Chris Fitzpatrick 
<chrisfitz...@gmail.com<mailto:chrisfitz...@gmail.com>>
wrote:

Vagrant is not a good idea for production. It's really for people to work 
against a copy of the production environment.
Like you can use Vagrant, then update a ansible or puppet or chef script then 
deploy that to yr VM.
Hashicorp is making something called Otto which is supposed to replace Vagrant 
for end-to-end deployments like this, but that's in alpha now.

Vagrant isn't  like virtualenv at all. Virtualenv is a way to maintain Python 
dependencies by mucking around with some environment variables.
It's
more like Ruby's bundler.

It's kinda more like Docker. Docker makes linux containers. Nobody knows what 
those are, but they work great.

I've seen Vagrant used in production and it supposedly worked well but the guy 
who set it up left and things went bad. It wasn't a performance issue, it's 
just really hard for the replacement to figure out what's going on.
Use Vagrant with Ansible/Puppet/Chef. Or use Docker. Or use all of that, for 
the win.



On Wed, Apr 6, 2016 at 3:55 PM, Francis Kayiwa 
<kay...@pobox.com<mailto:kay...@pobox.com>> wrote:

On 4/6/16 9:49 AM, Annamarie C Klose wrote:

Hi, all,

Can anyone provide a technical explanation as to why it is not appropriate to 
install Islandora on a public server with Vagrant?
Despite
all the documentation instructing that Vagrant is for development only, my 
university's IT department thinks Vagrant makes Islandora more secure for 
production use. They have also stated "Vagrant is used to keep dependencies 
separate on machines in the same way Pythons Virtualenv or Ruby's Docker is." 
Unfortunately, secure networking is outside of my expertise.
I'm concerned that Vagrant's virtualization is a poor substitute for the real 
thing. Before I add hundreds of records to Islandora, I'd like to make sure 
that I'm building my library's digital collections on a steady foundation.
Any advice and/or explanations to give IT is welcome.



If we agree  that your University IT are the Operations people find the nicest 
way to tell them how the developers of Vagrant view the tool below

https://www.vagrantup.com/docs/why-vagrant/

Specifically. "...If you are an operations engineer, Vagrant gives you a 
disposable environment and consistent workflow for developing and testing 
infrastructure management scripts..."

You are also correct in being wary about having a production application 
running on Vagrant. A part of me wants to test that just for laughs, but it 
will be painful to set up for them and the performance will horrible for you.

Cheers,
./fxk

--
"Anyone attempting to generate random numbers by deterministic means is, of 
course, living in a state of sin."
-- John Von Neumann

Reply via email to