Install the system at a customer site

This page shows the whole job of installing our platform at a customer site. It has seven steps. Each step has its own page with the details. For the words used here, see Words you need to know.

Before you start

This section lists what you need before step 1.

  • An account with the role user or higher. See People and roles.

  • Access to the installation you will work on, if you did not create it. See roles and installation access.

  • The training modules for the actions you will use. See Training.

  • The addresses of the customer’s servers, and a way to reach them over SSH. If the tool cannot reach the site, you can still create the bundle and carry it there.

The seven steps

Do these steps in this order. Each step gives you what you need for the next step.

  1. Choose a topology. A topology says which services to install, and which server each service runs on. Pick an existing topology on the Topologies tab, or create a new one. Several installations can use the same topology.

    Details: Step 1. Choose a topology

  2. Create an installation. An installation connects the topology to the customer’s real servers. You give it the customer, and an address for each server. It appears as one card on the Installations tab.

    Details: Step 2. Create an installation

  3. Fill in the variables. Variables are the settings that the services need. Most variables already have a default value. The tool asks for each secret once per name. For some values the tool does not make up a value. It asks you instead.

    Details: Step 3. Fill in the variables

  4. Create the bundle. The bundle is the package that goes to the site. It holds a compose file for each server, the configuration files, an environment file for each server, and the installer. It can also hold the container images.

    Details: Step 4. Create the bundle

  5. Test the bundle. Test install runs the bundle on temporary servers. The tool creates these servers and then deletes them. Nothing reaches a customer. This step is optional.

    Details: Step 5. Test the bundle

  6. Deploy. Click Deploy. The tool sends the bundle to the servers over SSH and installs it. You see a live log.

    Details: Step 6. Deploy

  7. Check that it works. Use Health to see what every service is doing now. Use Diagnostics to collect one file that you can read later.

    Details: Step 7. Check that it works

From a release to software running at a customer

This section shows the whole job, from the new version to a running system. It includes the steps that a person does by hand.

  1. A release is created and published in CI/CD Manager. A release is a set of service versions that belong together. It is sent to this tool automatically when it is published. Nobody needs to press anything here. If the release does not arrive, nothing here reports it. See how a release arrives.

  2. An operator creates or opens an installation. The operator connects its servers and answers its variables. At the version step, you can pick the published release. This fills in, in one action, the version of every service that the release names. The tool lists the services that the release does not name. Fill those in yourself. It only fills in the versions. It does not decide them for you.

  3. The tool generates a bundle. The tool refuses if the installation no longer matches its topology. It also refuses if a value is missing. The refusal names what is missing.

  4. Optionally, you run a practice install of the bundle on temporary servers. See Test install. This proves that the bundle installs. It proves nothing about the customer’s network, storage, firewall or hardware.

  5. The bundle goes to the servers. This tool can send it over SSH. Or someone carries it to the site and installs it by hand. About half of customer sites use the second way. This tool can never reach those sites. So for them, the last step below is a statement by a person. The tool does not see it.

  6. The install runs in steps, in the order that the topology requires. The servers in one step install at the same time. If a server fails, the other servers in its step still finish, and no later step starts. See Deploy.

  7. Someone confirms that the installation is live. This happens automatically when the deploy ran from here and finished without errors. Otherwise, someone marks it as installed. See install stages.

  8. The installation is verified, and later upgraded. An upgrade is the same sequence with one extra answer: the version that is already on those servers. It also has one extra protection. The tool takes a database dump before the first migration, because there is no schema rollback. See Update an existing installation.

For how a new operator goes through this the first time, see a new operator’s first day.

If something goes wrong

See When something goes wrong. It lists failures by what you see.