 |
 |
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:[log in to unmask]] On Behalf Of Harnum, Alan Sent: Friday, April 08, 2016 9:11 AM To: [log in to unmask] 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 [log in to unmask]<mailto:[log in to unmask]> On Apr 7, 2016, at 1:56 PM, Annamarie C Klose <[log in to unmask]<mailto:[log in to unmask]>> 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:[log in to unmask]] On Behalf Of Cindi Blyberg Sent: Wednesday, April 06, 2016 5:46 PM To: [log in to unmask]<mailto:[log in to unmask]> 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 <[log in to unmask]<mailto:[log in to unmask]>> 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 <[log in to unmask]<mailto:[log in to unmask]>> 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 <[log in to unmask]<mailto:[log in to unmask]>> 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