This guide starts after the onboarding of a new customer and helps to prepare the GoLive. The tasks in this guide are basically customer-led and can be supported by root360.

After onboading into the new environment, you will be able to independently move to the root360 platform and can now begin to integrate the application on the new infrastructure. Here are the basic steps to be taken to prepare the Go-Live. If it is successful, root360 offers the possibility for a DevOp to assist during the Go-Live and immediately intervene in case of errors.. Before Go-Live, it is advisable to create a checklist and share it with root360 so that a structured approach is possible to make the application available on the new infrastructure.

Deployment

Basic information about root360-deployment is available in the deployment category of the Knowledge Base.

Preparing the codebase

Before the first deployment ensure that the codebase is prepared accordingly. For this it is necessary that an install.sh file exists in the root directory of the application. For the first deployment this file could be empty. The install.sh gives you the opportunity to inject information from the environment variables into the application during the deployment. These include e.g. Database name, user name and password. At the same time, install.sh can be used to install cronjobs on the application servers or to control deployment via hooks.

Media files

Media files should be excluded of the deployment process and initially imported directly into the new environment. If a shared folder is present it's the right place for storing media data, which has to be accessible e.g by parallel instances within an autoscaling group.

You can access this directories from the Natgw / Jumpserver with the path /mnt/nfs/<company>-<project>-nfs. In the document root of a web server additional symlinks are set that point to these directories.

Run the first deployment.

Deployment is started via the root360 r3 suite. The following command will be executed on the Natgw / Jumpserver. 

Example deployment

Database

For security reasons, the database is located in the Application Zone and can not be addressed directly from a public network.

Importing data into the new database is possible in two different ways. The database Credentials can be obtained from the environment variables. First you can upload a database dump to the Natgw / Jumpgateway, which can connect to the database to import the dump.

The second way offers you the abillity to access the database using a ssh tunnel.

For more information see the the category database in our knowledge base.

Testing the environment

Thorough testing of the environment is essential. At this stage, e.g. PHP and database parameters are tested and adjusted to ensure a later stable running of the application. 

For a PHP application to be debugged as much as possible, root360-customers have the ability to use Tideways.io on their application servers, allowing them to keep a close eye on their PHP application and quickly locate any bottlenecks. If interested, just send a request to support@root360.de or open a ticket via support.root360.cloud to get a trial.

Mailing

Sending via an external SMTP server as a mail relay is a common way for secure e-mail delivery. It is also to be noted here that AWS monitors the port 25 for spam protection reasons and regglements if necessary. For more information see our mailing category.

Preparing the Go-Live

final sync of the database

The delta between the existing data in the database and the current productive database must be imported into the new database to ensure the integrity of the data.

Final sync of the shared folder / media files

All data in the shared folder must be updated to the state of the productive data.

Increase the resources

To save costs, resources are kept low until Go-Live. Shortly before the Go-Live, the resources are slightly over-provisioned to provide enough power and do not get overloaded. After reviewing the provided resources, they can be scaled back down or remain at that level. As a measure of resource size for the Go-Live, it is advisable to orientate yourself on existing resources and adapt them to the root360 platform.

Domains

Finally, the CNAME record of the respective DNS must be set on the domain of the Loadbalancer. That has to be a subdomain like www. This step must be done by the customer unless the DNS zone is located in Route53.

It is still possible to set an A-record if the root360 redirect service is used.

For more information see this article.

Certificates

If the application can be reached via SSL, then it is necessary to deposit certificates for the corresponding domains. Existing certificates can be used for this purpose, e.g. bought from a supplier. This is especially important when it comes to EV certificates. The certificates are deposited by root360 on the new infrastructure.

There is also the possibility to use certificates from Amazon. Via ACM it is possible to have free certificates issued by AWS. These certificates are fully integrated with AWS services. Preferably, these certificates are validated by DNS. To do this, the customer only has to deposit an AWS-generated CNAME for the respective domains. This has the advantage that these certificates automatically extend and no action on the part of the customer is necessary anymore. ( Excluded are EV certificates.)