A server is a virtual machine running in Tieto DevOps Space with installed and configured TDS supported operating system.
All Servers are managed by its project's users with proper rights.
Users with Project Owner rights have full responsibility for his/her project's Applications, servers management and security protection.
Servers page can be found in the main tab under SaaS and represents a list of virtual servers in projects. Each server in the list has information about server name, URL, status and Applications (if any).
The user also can add the server to Favorites by clicking on Star icon in the up-right corner for each server.
Click to server name redirects to Detail page:
|Detail||Basic details about the server including date of creation, authentication type, OS information, a username of the creator of the server|
|Connections||Information about connecting to the server, commonly via SSH or LDAP|
|Applications (if applicable)||List of applications installed on the server|
|Users||Users and their privileges on the server are managed from this page|
|Logs||List of events listed by date|
|Usage||Graphs about the usage of the CPU, RAM and Disk capacity|
|Backups||List of backups, user can enable/disable regular backups of the server|
|Settings||A page for changing server status and capacity. Admin can also Delete server from this page|
How to deploy new server
- step - Login into TDS portal.
- step -
- step - Next page named Store Config displays basic information about the server, estimated price and several checkboxes which can be filled.
User can change:
- hostname (at least 3 characters with at least 1 letter and 1 hypfen "-", maximum characters is 15).
- authentication method (login to the server via ssh)
- the capacity of the server (CPU, RAM and disk capacity)
- step - After all information is filled, clicking on the Order button will start creating the server. There are several types of information which are already pre-filled but can be changed.
Only some information needs to be filled.
SSH key management
Enabling certificates creates /data/ssl folder with relevant files:
- server.key - private key
- server.crt - certificate signed by relevant CA (Let's Encrypt or in some cases TDS)
- ca-bundle.crt - chain of root and intermediate certificates that signed the certificate
- fullchain.crt - chain of root, intermediate and server certificate (usually needed by Nginx)
You can optionally enable those certificate files when deploying server.
Self-managed PaaS applications (Gerrit, Jenkins, SonarQube) from TDS are automatically configured to use those certificate files.
You can also create hooks if you want to execute some commands after new certificate is deployed. Typically it is restart of some service. Also you can use hooks which can be automatically executed after each new certificate deploy - look for more in Certificatedeploymenthooks chapter.
CA certificates management
Certificates deployment config
Generally reload of httpd/apache2 is called during each certificates update. However in some cases we must various extra operations.
For that purpose hooks folder has been introduced with following default value:
As soon as there is anything executable present in hooks folder, it is automatically executed. Remember to handle also httpd/apache2 restart yourself as regular certificate update script skips apache restarts in cases when hooks are used.
If you like you can override hooks path by providing CERT_HOOKS_LOCATION variable in /data/configs/tdscertdeploy.conf config file.
Suppressing certificates deployment
Create following file which will make sure your certificates will not be touched:
Content of file:
To get certificates deployed automatically again during next renewal periods, just remove that file and automated certificate deployment will work.
Certificate deployment hooks
Hooks shall be bash scripts made executable and placed in folder /data/ssl/hooks folder. It will be automatically executed every time when new certificate is deployed.
Nginx certificates hook example
For Nginx web server it is recommended to have server certificate and intermediate certificates bundled in file configured by "ssl_certificate" directive:
Example of setting of correct certificate path in nginx files:
This is recommended setup verified by users: