What is Deployment Manager

This page is for a person who has never seen Deployment Manager. It says what the tool does, who uses it, and what you can do in it. It also explains the words that the other pages use.

Open Deployment Manager: deployment.friendly-tech.com

What it does

Deployment Manager installs our platform on a customer’s servers.

You choose what to install: which services, and which server each service runs on.
You fill in the settings that the services need.
The tool creates one package with everything in it.
The tool installs the package on the customer’s servers and shows a live log.
The tool checks that the services run.

Who uses it

These people work in Deployment Manager:

Support engineers. They install, update and check the platform at customer sites.
Deployment engineers. They plan which services run on which servers, and they install them.
QA. They test a package on temporary servers before it reaches a customer.
Administrators. They give people access and keep the settings of the tool.

What each person may do depends on their role. The roles, from lowest to highest, are: no_access, viewer, user, support_admin, global_admin. See People and roles.

What you can do in it

This list shows the main jobs. Each job has its own page.

Sign in and learn the screens. See Getting started.
Install the system at a new customer site, from start to end. See Install the system at a customer site.
- Choose which services to install, and which server each one runs on. See Step 1. Choose a topology.
- Connect that choice to the customer’s real servers. See Step 2. Create an installation.
- Type the settings and passwords the services need. See Step 3. Fill in the variables.
- Create the package that goes to the customer. See Step 4. Create the bundle.
- Try the package on temporary servers first. See Step 5. Test the bundle.
- Install the package on the customer’s servers. See Step 6. Deploy.
- Check that every service runs. See Step 7. Check that it works.
Update an installation to a new version. See Update an existing installation.
Find out why something failed. See When something goes wrong.
Ask the AI assistant a question while you work. See Ask the AI assistant.
Look at reports. See Reports.
For administrators: manage people, read the journal, change settings. See People and roles, Operations journal and Settings.

Words you need to know

This section explains each word that the other pages use.

Word What it means

Word	What it means
Service	One program of our platform. It runs in its own container.
Server	One machine at the customer site. One or more services run on it.
Topology	A plan that says which services to install, and which server each service runs on. It has no real server addresses. Several installations can use the same topology.
Installation	A topology connected to real servers and a real customer. Each installation is one card on the Installations tab.
Variable	One setting that a service needs, for example an address or a port. Most variables already have a default value.
Secret	A variable that must stay hidden, for example a password. The tool asks for each secret once per name.
Bundle	The package that goes to the customer site. It is one `.zip` archive. It holds the files that each server needs and the installer. It can also hold the container images.
Deploy	Send the bundle to the customer’s servers over SSH and install it there.
Test install	A practice install of the bundle. It runs on temporary servers that the tool creates and then deletes. It never touches a customer’s server.
Contract	A file that each service has in its own code repository. It says what the service needs: its variables, its secrets, and the other services it depends on.
Release	A set of service versions that belong together. It is created and published in CI/CD Manager, and then it arrives in this tool.
Health	A check that asks every server, live, what its containers are doing now.
AI assistant	A chat panel in the tool that answers your questions from our documentation. See Ask the AI assistant.

Service

One program of our platform. It runs in its own container.

Server

One machine at the customer site. One or more services run on it.

Topology

A plan that says which services to install, and which server each service runs on. It has no real server addresses. Several installations can use the same topology.

Installation

A topology connected to real servers and a real customer. Each installation is one card on the Installations tab.

Variable

One setting that a service needs, for example an address or a port. Most variables already have a default value.

Secret

A variable that must stay hidden, for example a password. The tool asks for each secret once per name.

Bundle

The package that goes to the customer site. It is one .zip archive. It holds the files that each server needs and the installer. It can also hold the container images.

Deploy

Send the bundle to the customer’s servers over SSH and install it there.

Test install

A practice install of the bundle. It runs on temporary servers that the tool creates and then deletes. It never touches a customer’s server.

Contract

A file that each service has in its own code repository. It says what the service needs: its variables, its secrets, and the other services it depends on.

Release

A set of service versions that belong together. It is created and published in CI/CD Manager, and then it arrives in this tool.

Health

A check that asks every server, live, what its containers are doing now.

AI assistant

A chat panel in the tool that answers your questions from our documentation. See Ask the AI assistant.

When something goes wrong

The page When something goes wrong lists failures by what you see. It helps you find out where the failure is. There are three places:

this tool
the software being installed, or its configuration
the server and the site around it

For the cases below, the first explanation that comes to mind is usually wrong. Start with the first table on that page for them.

The readiness checks refused before anything was installed. Nothing changed on that machine. So there is nothing to undo.
A container keeps restarting, but its log has no errors.
The database starts without problems but refuses every service. This happens right after a redeploy with newly typed passwords.
A service reports healthy long before it accepts clients. So every service that waits for it starts too early.
A service row reads not started, but the container next to it is healthy.

What it does not do

This list saves you time. Do not look for a screen that does not exist.

It does not manage Kubernetes environments. It does not build images. It does not create releases. Other tools do that.
It does not edit the files of a running installation on the server. When you change a variable, you change only what this tool stores. A deploy carries the new values to the server.
It never stops another program by itself to free a port. It shows the name of the process that uses the port. You can ask it to stop that process, and you must confirm first.
It does not read a customer’s server unless a person presses a button. Probing, Health and Diagnostics all open SSH. Each one is an action that a person took.

Reporting a defect

Report a defect from the screen where it failed. Use the button on the panel.

The button attaches the installation, the end of the log, and what the assistant said.
The person who reads the ticket does not need to ask you for these.
If you type the ticket an hour later, this information is lost.

If the reason was not found, say so. Do not guess. A failure with no reason is a finding too. For what to attach, see what to attach to a ticket.