Simplifying Deployment with Official Virtual Appliance
-
@wayne-workman said in Simplifying Deployment with Official Virtual Appliance:
Yeah, at this point Fedora would be a better pick for RPM based Linux than CentOS.
I agree 100%. At this point CentOS is dead to me.
I think people should learn Debian.
As we roll out new linux VMs, they will be Debian at my company. As you said Ubuntu is very popular, but (IMO) Canonical could go the same route as RH or go a totally different route causing a new bunch of problems. Heck, Canonical could get sucked into Microsoft, then what? (Embrace, enhance, extinguish. You know the drill.)
-
We use Ubuntu where I am (US K12) I manage updates via Landscape which as worked out pretty well for us. Mind you our Linux footprint is much smaller than our Windows Server footprint.
I would definitely be behind a Debian based Appliance and would be willing to seed from home as well. I had to cut my speed from gig to 200/200 for reasons, but still enough to be helpful.
The biggest wrinkle would be scripting the first startup to ask the appropriate questions and making the appropriate changes (disk size, Database PW, network interface, IP, Hostname, generate Certs(SSL Should be a default on an appliance), etc.)
-
@astrugatch et al.
An OVA would be a decent approach, but then it puts the onus back on the FOG developers to manage the OVA, manage the updates, make sure documentation is all up, while also maintaining the FOG GUI and imaging system.
While the OVA approach is seen as a “yeah that would make my life easier” it doesn’t really make much sense.
If anything, a docker container would probably be a better and more security based approach. It allows us to work in one relatively simple environment. There’s some complexity involved here as well of course, but no where near as much as it would be to maintain an entire Virtual Appliance along with updates to the OS, managing templating and customization features, managing upgrade paths, etc…
Ultimately, the goal is to move away from a linux required environment (and I have been slowly working on it as well) and migrating from PHP based GUI/API to a NodeJS based GUI and API. This means you could install fog using simple management commands with being OS agnostic such as: npm install fog-node (or something like that). This could be done on Windows, Mac OS X, and/or linux using a common path. Plus it removes the onus of OS management giving it back to the Administrator.
The docker container, I think, is the middle man approach that would accomplish a similar feat as OVA without as much overhead for management though. Plus, realistically, it can be done much quicker and compartmentalizing more of the components such as TFTP, NFS, HTTP/S, etc…
-
A docker container is a good idea.
I was thinking with a VM image using Debian, I could pull down the packages FOG needs locally, and set apt-get to use those local packages. All the packages would also be pre-installed in the image.
As far as running something first-boot, if I’m building it I wouldn’t set it up like that. I’d say the admin can log into the VM (however they do that), and just run the fog installer which would already be there for them.
With this approach, there’s no changes to the installer or the code base. I hoped to automate building this image, creating a new one with each FOG release, and distributing via torrent.
If admins want to update, they would need internet and comment/uncomment some lines in their
sources.listfile, and update the fog repo withgit pull.Because the OS would be a chosen one, I can write up some documentation on setting a static IP, as well as putting a readme in the image saying the same.
Though a docker image is good too. idk if it would be easier or not. I don’t know docker very well.
-
I’m also down with making a Ubuntu image. Since that seems to be most popular. I wouldn’t want to mess with more than one.
-
I lean toward a VM over docker only because docker takes a different skill set where with a VM beginners can simply load up virtual box or power users likely already have something like VMware or Xen in their environment. That’s not to say that there isn’t value both for the dev team and users for a docker container.
I would lean toward Debian personally especially with some of the SQL idiosyncrasies with Ubuntu. Though I could see the value in going Ubuntu given how popular it is with the current user base.
-
Reviving this thread on my lunch break. What would a docker container for FOG look like?
Immediate thoughts:
- specify via environment variables database configuration for some external DB.
- Specify via environment variables the other things found in
/opt/fog/.fogsettingstoo. - disk mounting for images.
For the VM image, I could probably get this going in a couple weekends. In my VM environment at home, I can create qcow2 disk types. Though I can convert
qcow2tovmdkrather easily. Could make aqcow2as well asvmdktorrents individually for distribution. -
vmdk is probably the most broadly cross compatible short of something like an ova
-
@wayne-workman
Just checking to see if you’ve moved on this at all or if there is anything I can do to lend a hand. I have a decent sized lab with both Xen and ESXi if anything needs testing. -
@astrugatch I haven’t done anything on this yet.
@moderators would there be any issue with using a forums topic to host torrent files for a fog VM image?
