Must have software stack for a mobile employee

semaphore said:
Vagrant.
Click to expand...

I get the Vagrant part, but what benefit do you have over just running a snapshot/base image with the right stack which you can just clone over and over?

As an example: We have a number of different stack images which are maintained by our Linux team (built via Chef/Puppet). The stack-images are available as OVA/VBOX etc and on top of it we automate the bootstrapping of other stuff (i.e. databases with restore from production or just an empty DB with static data). As a developer I take one of those snapshots (3-20GB depending on data) and run with it. I use snapshots in case I need to go back. I clone a base image if I need another instance.

As far as a I understand, Vagrant "just" creates a VBox and manages it via scripts (almost like a Chef/Puppet). How long does it take to provision an image from the ground up (compared to just copying an existing one?)? I guess it all depends on how often you have to recycle/refresh virtuals (we hardly ever, but do refresh data automatically on those images).

BTW: The OVA images we use in dev/QA are the same we apply to production - so there is no risk that a developer runs on a stack which is too old or too new and potentially causes compatibility issues (i.e. newer Java stack on dev vs what is on production).
 
MagicDude4Eva said:
I get the Vagrant part, but what benefit do you have over just running a snapshot/base image with the right stack which you can just clone over and over?

As an example: We have a number of different stack images which are maintained by our Linux team (built via Chef/Puppet). The stack-images are available as OVA/VBOX etc and on top of it we automate the bootstrapping of other stuff (i.e. databases with restore from production or just an empty DB with static data). As a developer I take one of those snapshots (3-20GB depending on data) and run with it. I use snapshots in case I need to go back. I clone a base image if I need another instance.

As far as a I understand, Vagrant "just" creates a VBox and manages it via scripts (almost like a Chef/Puppet). How long does it take to provision an image from the ground up (compared to just copying an existing one?)? I guess it all depends on how often you have to recycle/refresh virtuals (we hardly ever, but do refresh data automatically on those images).

BTW: The OVA images we use in dev/QA are the same we apply to production - so there is no risk that a developer runs on a stack which is too old or too new and potentially causes compatibility issues (i.e. newer Java stack on dev vs what is on production).
Click to expand...

Could you elaborate on this. Sounds like it could solve some of my problems with people using outdated DB versions.
 
MagicDude4Eva said:
I get the Vagrant part, but what benefit do you have over just running a snapshot/base image with the right stack which you can just clone over and over?

As an example: We have a number of different stack images which are maintained by our Linux team (built via Chef/Puppet). The stack-images are available as OVA/VBOX etc and on top of it we automate the bootstrapping of other stuff (i.e. databases with restore from production or just an empty DB with static data). As a developer I take one of those snapshots (3-20GB depending on data) and run with it. I use snapshots in case I need to go back. I clone a base image if I need another instance.

As far as a I understand, Vagrant "just" creates a VBox and manages it via scripts (almost like a Chef/Puppet). How long does it take to provision an image from the ground up (compared to just copying an existing one?)? I guess it all depends on how often you have to recycle/refresh virtuals (we hardly ever, but do refresh data automatically on those images).

BTW: The OVA images we use in dev/QA are the same we apply to production - so there is no risk that a developer runs on a stack which is too old or too new and potentially causes compatibility issues (i.e. newer Java stack on dev vs what is on production).
Click to expand...

I have prebuilt images for my environment, basically the same way you do it.And just use vagrant to switch and control them. You could ultimately just use the virtualbox application.

I've never really timed the recycle process, but I havnt in a while either.
 
Pho3nix said:
Could you elaborate on this. Sounds like it could solve some of my problems with people using outdated DB versions.
Click to expand...

It is actually quite a simple process:
- We run a daily process which just dumps the schema and static tables into SQL scripts and then versions it. For a clean provision of an empty DB, we just drop the DB and then re-create from those scripts.
- When we drop a production DB into our staging environment (the DB is about 300GB), it is a simple restore process. We do not need to anonymise data as sensitive data is encrypted and has access control.
- For developers needing a sample-set of data we literally dump data-population scripts in the form of "SELECT * FROM TABLE X where LASTCREATEDTIME > SYSDATE - 30" (i.e. for the last 30 days).

As part of our release processes we obviously have delta-DB-update scripts and developers typically apply those to their own DBs. With the above we never have any issue with outdated DBs.

There is obviously more to it, and you should really apply for a job, then you get all the insight and wisdom :whistle:
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X