Valentin Lab
be952660ce
|
1 year ago | |
---|---|---|
apache | 2 years ago | |
bind | 2 years ago | |
bitwarden | 2 years ago | |
collabora | 1 year ago | |
cron | 4 years ago | |
cyclos | 2 years ago | |
cyclos-ui | 4 years ago | |
docker-host | 6 years ago | |
docker-registry | 6 years ago | |
docker-registry-auth | 5 years ago | |
docuseal | 1 year ago | |
drone | 4 years ago | |
drone-agent | 6 years ago | |
etherpad | 2 years ago | |
gitea | 2 years ago | |
gitlab | 6 years ago | |
gogocarto | 1 year ago | |
gogocartojs | 5 years ago | |
hedgedoc | 3 years ago | |
hugo | 2 years ago | |
itty-bitty | 3 years ago | |
keycloak | 3 years ago | |
letsencrypt | 3 years ago | |
lo-xcgd | 5 years ago | |
logrotate | 4 years ago | |
mailhog | 3 years ago | |
mariadb | 1 year ago | |
mattermost | 5 years ago | |
minecraft | 2 years ago | |
mongo | 1 year ago | |
monujo | 2 years ago | |
mysql | 4 years ago | |
nextcloud | 1 year ago | |
odoo-tecnativa | 1 year ago | |
onlyoffice | 2 years ago | |
peertube | 3 years ago | |
piwigo | 4 years ago | |
postgres | 1 year ago | |
postgres-alpine | 6 years ago | |
precise | 1 year ago | |
py3o-fusion | 5 years ago | |
py3o-server | 5 years ago | |
radicale | 2 years ago | |
rancher | 6 years ago | |
rancher-agent | 6 years ago | |
redis | 5 years ago | |
rocketchat | 3 years ago | |
rsync-backup | 4 years ago | |
rsync-backup-target | 1 year ago | |
searx | 4 years ago | |
sftp | 3 years ago | |
smtp-stub | 1 year ago | |
softether | 8 years ago | |
solid | 2 years ago | |
synapse | 3 years ago | |
traefik | 6 years ago | |
vsftp | 6 years ago | |
whoami | 7 years ago | |
README.org | 1 year ago |
README.org
0k-charms
This package provides charms, which are special system recipes, that are meant to be executable and mangled together to allow managing a wide set of services.
Inspired by juju charms, these are mostly bash scripts organized by service and meant to automate all administration tasks, from installation, to connection with other services, or any other task a service would need.
Several tools are able to read the current state of this repository to effectively deploy full production grade services on different type of platform.
The only real fully functional implementation is 0k-compose
. It will
use these charms to drive, prepare, and build in docker
, complete sets
of services.
Another old solution called lxc-deploy
was used actively before to deploy
services on LXC tool set until 2016 using these charms.
Bare hosts can also replay some recipes to install services directly
on them via the 0k-charm
project using the charm apply
command. Note that actually, as most recipes are bash executable, it
is still a viable option to copy-paste parts of source-code of these
scripts. These last two options are still used very often to bootstrap
installs of docker-hosts
for instance.
Maturity
Charms in these repository are in a wide set of maturity, from simple note taking of shell commands, not even executable, to full charm allowing to deploy services and manage the full life cycle of the service.
The repository in a whole is thus NOT considered as mature at all, and will require some thorough cleaning and decisions to furthermore structure to reach a state where it'll make sense to go full public.
Usage
TODO
Through compose
for full deployment of sets of services
Requires 0k-compose
package that contains the compose
command line tool.
TBD
TODO
Through lxc-deploy
for full install and deployment of services
Requires lxc-scripts
package that holds several tools for LXC
management, amongst them is lxc-deploy
.
TBD
TODO
Through docker-build-charm
for docker image creation
Requires 0k-docker
package that holds several tools for docker
management, amongst them is docker-build-charm
.
docker-build-charm
will use the install
recipes in a charm to
basically mimic the Dockerfile
purpose and create a docker image for
a specific service.
TBD
TODO
Through 0k-charm
for bare hosts installs
Requires 0k-charm
package to get the charm
command line util.
TBD
Installation
Most tools should check the CHARM_STORE
bash environment variable
that should be the path to reach the root of this repository. If not
defined, most tools will look in /srv/charm-store
by default.
Specs
charm type
Not all charm are intended to bring up services as having a container always running and listening.
In metadata.yml
, the root level type
can be one of:
-
service
(default)If not specified, this is the default. A charm brings up a service. It is meant to be always running. For instance,
apache
,mysql
,postgres
are services.They usually open ports and are listening to provide their service, or carry background listening of other ressources (like checking time and sending scheduling command for the
cron
services), and or use files to trigger or report on their activity.It will have an entry in the final
docker-compose.yml
, and thus, a container will run and stay in memory and have arestart: unless-stopped
policy. They use CPU and memory ressources. -
run-once
The entry is meant to describe a command that run once, it will be called by a service and will exit after execution.
For instance,
logrotate
,rsync-backup
, orletsencrypt
are of typerun-once
.They are meant to be run by service for specific events. They usually will use relations to ensure they are called at specific moment by service…
A command does not have an automatic
restart
policy as services have.They use CPU and memory ressources only when run and gives them back once finished.
-
stub
The entry describes an entity that will not be run at all. It is used to hold information in the
compose.yml
and often to stand for a real service managed outside ofcompose.yml
(on an other host or on a different managing system, like a local installation or LXC, virtualbox, …).For instance,
stmp-stub
can be used to stand for an externalsmtp
.It is through their relation that they shine as they can provide similar interface than actual services would have provided.
smtp-stub
is asmtp-server
provider and other charm can connect to it.They usually implement relation hooks, and are providers.
No entry will be created in the final
docker-compose.yml
.They use no CPU or memory ressources at all.