App-LXC-Container
view release on metacpan or search on metacpan
- reverted bad fix for smoker detection
0.28 2023-09-19T08:17:36Z
- removed some obsolete FIXMEs and diagnostics in tests
- leaving pre-alpha test phase
- fixed wrong smoker detection
0.27 2023-09-01T09:10:02Z
- updated dependecy to UI::Various to hopefully fix deep recursions
0.26 2023-08-31T12:05:35Z
- t/02-init.t: added further debugging for UI::Various (still checking deep recursions)
0.25 2023-08-30T14:39:27Z
- t/02-init.t: added debugging for UI::Various (still checking deep recursions)
0.24 2023-08-29T11:40:16Z
- -
The concept is not useful if you need to run and scale an application
across several machines.
These disadvantages are compensated by several advantages:
- +
All applications are automatically updated together with the Linux
distribution of the machine.
- +
The applications do not need additional disk space (except for the
configuration files as well as some directories, bind-mounts and symbolic
links - we're writing about 250-2500 additional inodes and 500-2500 kB of
disk space).
- +
attacks like Heartbleed etc.) and more secure than any type of container.
- +
The images for virtual machines need a lot more disk space and main memory
as nothing is shared with the main system (even more than Docker
containers).
- +
Virtual machines must be updated separately from the main system.
- +
Starting an application inside of a virtual machine is slower than starting
an application container.
_Additional advantages/disadvantages are welcome._
# BEST PRACTICES
### description:
This is the actual code for the wrapper script `lxc-app-setup`.
## **update** - update LXC configuration
App::LXC::Container::update(@containers);
### parameters:
@container name of the container(s) to be updated
### description:
This is the actual code for the wrapper script `lxc-app-update`.
## **run** - run LXC configuration
App::LXC::Container::run([@options,] $name, <program> [, <program-options>]);
### parameters:
lib/App/LXC/Container.pm view on Meta::CPAN
across several machines.
=back
These disadvantages are compensated by several advantages:
=over
=item +
All applications are automatically updated together with the Linux
distribution of the machine.
=item +
The applications do not need additional disk space (except for the
configuration files as well as some directories, bind-mounts and symbolic
links - we're writing about 250-2500 additional inodes and 500-2500 kB of
disk space).
=item +
lib/App/LXC/Container.pm view on Meta::CPAN
attacks like Heartbleed etc.) and more secure than any type of container.
=item +
The images for virtual machines need a lot more disk space and main memory
as nothing is shared with the main system (even more than Docker
containers).
=item +
Virtual machines must be updated separately from the main system.
=item +
Starting an application inside of a virtual machine is slower than starting
an application container.
=back
I<Additional advantages/disadvantages are welcome.>
lib/App/LXC/Container.pm view on Meta::CPAN
}
#########################################################################
=head2 B<update> - update LXC configuration
App::LXC::Container::update(@containers);
=head3 parameters:
@container name of the container(s) to be updated
=head3 description:
This is the actual code for the wrapper script C<lxc-app-update>.
=cut
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
sub update(@)
lib/App/LXC/Container/Mounts.pm view on Meta::CPAN
$mounts->merge_mount_points(12);
... foreach $mounts->sub_directories($path);
say $out $_ foreach $mounts->implicit_mount_lines('/');
$mounts->create_mount_points('/');
=head1 ABSTRACT
This module is used by L<App::LXC::Container::Update> to manage the
(possible) mount-points of a container that is updated.
=head1 DESCRIPTION
The module handles all kinds of mount-points of an LXC container
configuration created (and maybe destroyed again) during the update of an
LXC container.
=cut
#########################################################################
lib/App/LXC/Container/Run.pm view on Meta::CPAN
App::LXC::Container::Run - run real LXC configuration
=head1 SYNOPSIS
lxc-app-run [{-u|--user} <user>] [{-d|--dir|--directory} <directory>] \
<container> <command> <parameters>...
=head1 ABSTRACT
This is the module used to run a command inside of an LXC application
container previously created or updated with L<App::LXC::Container::Update>
(via its calling script L<lxc-app-update>). It is called from
L<lxc-app-run> via the main module L<App::LXC::Container>.
=head1 DESCRIPTION
The module starts the specified container and runs the given command either
as the user specified with the C<--user> option or as the root account of
the container if no other user is given. Note that the root account of the
container usually is restricted to the container, unless explicitly
configured otherwise (which usually is a bad idea). Likewise any other user
script/lxc-app-run view on Meta::CPAN
=head1 ABSTRACT
main script used to run a previously configured LXC application container
Note that the script must be called as root (see L<App::LXC::Container::Run>
for details).
=head1 DESCRIPTION
This script runs a command inside of an LXC application container previously
created or updated with L<lxc-app-update>. Parameters following the command
are passed through unmodified. If no user is specified, the command runs as
C<root>, which is a root account especially restricted to the container
unless explicitly configured otherwise (usually a bad idea). Likewise
another given user is restricted unless explicitly added to the list of
allowed users for the configuration (usually not a bad idea). The command
is run in C</> or the specified directory.
Note that the previously created configuration for LXC itself contains a
mandatory C<MASTER> comment in the second line. This comment may not be
deleted or modified, otherwise the start of the container may fail or the
( run in 0.289 second using v1.01-cache-2.11-cpan-05444aca049 )