* 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 [[https://discourse.juju.is/t/introduction-to-juju-charms/1188][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 a ~restart:
  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~, or ~letsencrypt~ are
  of type ~run-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 of ~compose.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 external ~smtp~.

  It is through their relation that they shine as they can provide
  similar interface than actual services would have
  provided. ~smtp-stub~ is a ~smtp-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.