Software deployment is usually realized through a publicly accessible git repository (for example on Github). For this purpose you need to store the deploykey (provided by root360) with read-only privileges in the repository. We discuss further details with you during your project migration.
Root360 provides the environments as required. The following abbreviations are used:
PROD = production environment, live environment
TEST = test environment or also staging / acceptance system
Network of an environment
An environment always consists of 3 zones, Public DMZ, Application Network and Gateway DMZ.
1. Public Network (DMZ)
In this zone, load balancers are provided for public access via HTTP and / or HTTPS. The used ports are preconfigured by root360. Optionally SSL offload (translation of HTTPS to HTTP) can be activated on the load balancers.
2. Application Network (private)
All services are provided within this zone. In addition, application instances and database instances are separated by independent subnets. Communication to public services on the Internet is not restricted and is routed via the (NAT) gateway.
The public IP address is therefore always the public IP address of the (NAT) gateway or the AWS gateway for all instances.
3. Gateway Network (DMZ)
The gateway in this zone takes the routing into the application zone for SSH access and regulates Internet traffic from the application instances.
If the agentforwarding is configured correctly, you can switch directly to an instance from the gateway using ssh XX.XX.XX.XX.
A SSH portforward (tunnel) can be set up to access services in the Application Network, such as Database, ElasticCache, SOLR, or similar by follow this FAQ https://root360.atlassian.net/wiki/spaces/KB/pages/2014351825 This allows each user whose OpenSSH key is present on the gateway to connect from their workstations to these services.
Deployment is controlled by the https://root360.atlassian.net/wiki/spaces/KB/pages/2014350252 tool on the bastion host. Note that all environments that use auto-scaling groups use this deployment process. Environments with single instances can deploy their application also without the use of the root360 cli suite, if so desired.
Deployment always runs in the following steps:
Updating the software sources via GIT, Github or similar (configured by root360)
Save the new release in the root360 environment, but not yet on the application instances
Distribution of the new release to all running application instances of the selected roles e.g. "web" or "backend". The production path (e.g. /var/www/) on the application instances does not yet point to that release.
Install the software using the bash script install.sh and learn how to use install.sh at https://root360.atlassian.net/wiki/spaces/KB/pages/2014352817. Possible applications are e.g. - adding the DB configuration to certain configuration files, - deleting local cache directories, - Run Composer - or the installation of CRON jobs.
Point the production path (e.g. /var/www/) on each instance to the new, installed release via a symlink
CRON jobs are installed on the instances in step 5 through the install.sh. The implementation in Bash is shown in the example at https://root360.atlassian.net/wiki/spaces/KB/pages/2014352817 . The CRON jobs are started parallel on all instances. If this is not intended or leads to problems, a separate role e.g. "cron" can be provided. The configuration of this role allows only one active instance, which avoids parallel execution.
In the standard configuration, most logs, such as Apache2 or NGINX, are stored centrally on the (NAT) gateway by all instances. The logs are stored on the instance in