Quoting Iliyan Stoyanov <i...@ilf.me>:
> I usually run redhat based LXCs (centos, SL, rhel), but I also ran a 32
> bit squeeze containers. What I usually do is either use yum (in redhat's
> case) to create an environment, then chroot to it and finish the set up,
> or use debootstrap for a minimal debian/ubuntu/whatever_deb_based
> install, then again chroot to it and install with apt-get what else is
> needed. Then I proceed to setup the rc scripts and create a container
> with lxc-create. It's a bit more work than using the templates but I
> tailor the containers to my exact needs. However I wouldn't recommend
> this approach for a large deployment, as it is time consuming. I too
> would love to hear ideas for large automated deployments, thought.
>
> BR,
> --ilf
My day job has had me building and experimenting with
various container rootfs, not for an enterprise play like
most folks on this list, but the basics are still the same.
I'm not saying this is the best approach, but I know it works.
I know there are lxc special ways and templates, but when I learn
something I want it to be generic enough to be applied to other needs.
Other than using these lxc commands, everything I do is basic debian:
lxc-create
lxc-destroy
lxc-start
lxc-stop
I start with two shell scripts, one that runs on the host and
one that runs within chroot environment, called by the first script.
The first script does these basic steps:
1) set shell variables, might specify: SEED, ARCH, etc.
2) call debootstrap with single ubuntu seed, currently one of:
ubuntu-minimal
ubuntu-standard
ubuntu-desktop
(is there an ubuntu seed for enterprise, probably server?)
3) run post-install script in new rootfs that might do any of these:
apt-get commands (update, upgrade/dist-upgrade)
apt-get install container package that fixes things initially
dpkg-reconfigure commands
useradd / groupadd commands (need for lxc-console)
???
clean out package cache (rm /var/cache/apt/archives/*.deb)
4) tar up new rootfs
Everything else I do within container environment on host,
I mean we are creating a container rootfs right?
The container package installed in step 3 makes whatever
one-time container rootfs changes are required. As a for example,
there are a few upstart job scripts that probably want to be
disabled.
Probably a bit of philosophical discussion to decide what gets done
in post install script versus what gets done in container package.
Once you are up and running inside the container, use basic apt-get
and dpkg commands to fully seed the rootfs. It is about a 4-line shell
script to step through a text file with a list of packages to install.
As packages are added be aware that you will have to re-visit /etc/init
and see what new upstart job scripts have been installed. I use this
command to help me keep up to date with the upstart job scripts, this
provides list of packages that currently have upstart job scripts installed:
dpkg-query -S "/etc/init/*" | sort
Is this a fully automated process, no?
The post install script may do commands, like dpkg-reconfigure
that may need interactive input. It also depends on package correctness,
e.g., the ubuntu-desktop package seems to have a broken dependency
regarding java runtime and fails to install correctly. This is
reoverable, again using basic apt-get and dpkg commands.
It is repeatable and what I have found to be the most automated
way for me to get my job done.
If interest on the list for the initial scripts I use, I will
check and see if I can post them.
Cheers,
T.mike
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
