 |
 |
Thanks everyone for your responses. I don't think I was very clear with part of my communications. IT will actually be the ones configuring the hardware and likely installing the OS and perhaps even the web service. From there we will get superuser access and install our own dbs and packages. The hardware itself will be out of our control. It will likely be part of their Virtual Server farm. While this means it won't actually be set in stone, from a practical side, we don't want to have to go back and ask for more everytime we develop a new app. I like the idea ensuring we have resources to do both OS level imaging and docker. IT has the ability to snapshot the servers, so I think we could ask them to run this periodically on our server, but most of the changes wouldn't be happening on the OS level side, so I like the idea of Docker as well. I will definitely need to get more proficient with it. I have only played with it a bit on my local PC. Thanks, Julie. -----Original Message----- From: Code for Libraries <[log in to unmask]> On Behalf Of Kyle Banerjee Sent: Tuesday, August 7, 2018 2:07 PM To: [log in to unmask] Subject: Re: [CODE4LIB] Web Server Specs? It might be worthwhile having a conversation to get a feel for what they're equipped to support and what the cost structure will look like for the library. Sometimes, resources that are easy and cheap to provision on the open market can be difficult and (very) expensive to obtain locally. Also find out what support looks like, what kind of disaster recovery options are available, what policies they have regarding connections/services, etc. As this is a dev environment, specific things you might want to ask about include imaging machines and rebuilding. When doing these things is easy, you can develop very aggressively. Whenever something works, take a new image you can work from in future. Whenever something blows up, dump the server and reconstitute from your latest good image. It's much easier to work if you don't have to worry about messing things up. kyle On Tue, Aug 7, 2018 at 12:08 PM Cary Gordon <[log in to unmask]> wrote: > Ideally, they should give you a mini-monster server so you could spin > up your own VMs or run Docker. Actually, Docker would be a great way > to go. I would want at least 8 GB RAM and 4 cores, although I would > ask for at least double that. > > Of course, in my world, I would just spin up nano and micro instances > on AWS as I needed them. I run scripts to turn them off when they are > not being used. If you need to test on bigger hardware, use spot instances. > > If hardware is free for you, then you'll be sticking to it, I presume. > > Thanks, > > Cary > > On Thu, Aug 2, 2018 at 1:56 PM, Julie Cole <[log in to unmask]> wrote: > > > Good point, although in a VM environment it is likely outside our > control, > > and might be hard to justify an exception for a sandbox server. > > Julie > > > > -----Original Message----- > > From: Code for Libraries <[log in to unmask]> On Behalf Of > > Edward Almasy > > Sent: Thursday, August 2, 2018 1:19 PM > > To: [log in to unmask] > > Subject: Re: [CODE4LIB] Web Server Specs? > > > > On Aug 2, 2018, at 2:27 PM, Julie Cole <[log in to unmask]> wrote: > > > We plan to install a LAPP or LAMP stack on it. (maybe both > > > databases?) > > I don't see this as being a very heavy transaction oriented environment. > > Some thoughts of things we would like to do with it: > > > This will likely be a virtual server, so it won't be written in > > > stone, > > but I'm still unclear on how much to ask for in terms of CPU, Memory > > and RAM. > > > Any tips, pointers, gotchas? > > > > If possible, get an SSD for storage. In addition to the obvious > increased > > general responsiveness, it’ll make many development and maintenance > > tasks far less onerous. > > > > Ed > > > > > > -- > > Edward Almasy <[log in to unmask]> Director • Internet Scout > > Research Group Computer Sciences Dept • U > of > > Wisconsin - Madison > > 1210 W Dayton St • Madison WI 53706 • 3HCV+J6 > > 608-262-6606 (voice) • 608-265-9296 (fax) > > > > > > > -- > Cary Gordon > The Cherry Hill Company > http://chillco.com >