taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

commit 10f13f6f9fbcf6aead7ed1858b05b25c2ed530c9
parent d6af628530119ca5772f4e47dd67f8d1a01e000b
Author: Devan Carpenter <devan@taler.net>
Date:   Thu, 25 Jul 2024 15:16:51 -0400

developer man: update section on demo deployments

Manual is updated to reflect the migration to using sandcastle-ng, as
well as systemd to manage the lifecycle of the demos instead of docker
commands.

Resolves Mantis ticket #8967

Diffstat:
Mtaler-developer-manual.rst | 62++++++++++++++------------------------------------------------
1 file changed, 14 insertions(+), 48 deletions(-)

diff --git a/taler-developer-manual.rst b/taler-developer-manual.rst @@ -389,72 +389,38 @@ you need a sub-domain to be added, please contact one of them. User Acccounts -------------- -On ``gv.taler.net``, there are four system users that are set up to +On ``gv.taler.net``, there are three system users that are set up to serve Taler on the Internet: -- ``taler-test``: serves ``*.test.taler.net`` and gets automatically - built by Buildbot. +- ``head``: serves ``*.head.taler.net`` and gets automatically + built by Buildbot every 2 hours from the ``sandcastle-ng.git``. + Master key may be reset occasionally -- ``taler-internal``: serves ``*.int.taler.net``, and does *NOT* get - automatically built. + - ``taler-test``: serves ``*.test.taler.net`` and does *NOT* get + automatically built, and runs more recent tags and/or unreleased + versions of Taler components. Master key may be reset + occasionally. - ``demo``: serves ``*.demo.taler.net``. Never automatically built. - + Master key is retained. Demo Upgrade Procedure ====================== #. Login as the ``demo`` user on ``gv.taler.net``. -#. Pull the latest ``deployment.git`` code. -#. Navigate to the ``deployment.git/docker/demo`` directory. -#. Refer to the README, or the smaller cheat sheet below. - -The deployment is based on rootless Docker, managed by the -SystemD unit in userspace: ``docker.service``. The running daemon -is reached by every Docker command at the address held into the -``DOCKER_HOST`` environment variable. Normally, it points to -``unix:///run/user/$(id -u)/docker.sock``. Such variable is automatically -exported by ``~/.bashrc``. - -.. note:: +#. Pull the latest ``sandcastle-ng.git`` code in checkout at ``$HOME/sandcastle-ng``. +#. Run ``systemctl --user restart container-taler-sandcastle-demo.service`` +#. Refer to the sandcastle-ng README (https://git.taler.net/sandcastle-ng.git/about/) + for more info. - Should the rootless Docker be installed, run the following command - or consult the `official documentation <https://docs.docker.com/engine/security/rootless/>`_. - - .. code-block:: console - - $ curl -fsSL https://get.docker.com/rootless | sh Upgrading the ``demo`` environment should be done with care, and ideally be coordinated on the mailing list before. It is our goal for ``demo`` to always run a "working version" that is compatible with various published wallets. Please use the :doc:`demo upgrade checklist <checklists/checklist-demo-upgrade>` to make sure everything is working. -Nginx is already configured to reach the services as exported by -Docker Compose. - - -Cheat sheet ------------ - -All commands run from deployment.git/docker/demo. - -.. code-block:: console - - # Start services. - $ docker-compose start --remove-orphans -d - - # Stop services. - $ docker-compose stop - - # Build base image (without tags-file builds master) - $ ./build_base.sh images/base/Dockerfile [tags-file] - - # Build all the services based on the latest base image - $ docker-compose build +Nginx is already configured to reach the services as exported by the user unit. - # View live logs of the daemonized services. - $ docker-compose logs Tagging components ------------------