Managed Kubernetes Usage

When hosting Magento and other applications in Kubernetes, each component of the web stack runs in its own container. This provides considerable benefits in terms of scalability, health checks, self healing components and precisely defined cron execution. While application functionality is equivalent to an M.D.G. IT VPS or AWS EC2 instance, there are differences that developers need to take into account when interacting with the hosting environment.

Configuration

All M.D.G. IT Kubernetes environments are deployed from version controlled configuration files. The advantages of this are significant:

• The configuration of the entire environment at any point is precisely defined, and any previous environment state can be redeployed

• Upgrades and component changes happen without downtime, because Kubernetes waits for a replacement pod to be up before routing the service to it. As an example, PHP 7.4 will keep serving requests up to the time that PHP 8.1 is available and takes over requests sent to php-fpm.

Outside of the yaml files that define the infrastructure itself, configuration files and variables are similarly stored in version control and passed in as ConfigMaps and Secrets, allow decoupling of environment-specific configuration from container images.

The above creates precisely controlled environments with absolute replicability, which however require certain changes in workflow:

• Service installation and upgrades are performed upstream; you cannot log in to a server and run yum install php83-php-opcache, for example

• Service configuration files are likewise deployed into an environment, and cannot be edited directly from within the environment

Both of the above make sense when considering that any given shell will be running on a specific container and so any changes would only affect that particular container, of which there may be eight replicas.

We can provide direct access to configuration files for developers who are fluent in YAML and Kubernetes configuration and need precise control over their environment. In most situations however we encourage clients to take advantage of our containerisation and Kubernetes expertise and provide us with their requirements so that we can build a robust hosting environment tailored to the application.

Environmental variables

As with ConfigMaps whose contents are available as files mounted on the file system, it is also possible to pass in key value pairs which are available to the container as environmental variables. These can, for example, define service port numbers, hostnames and other service information, with the added advantage that they will change dynamically if the source of the data is updated.

M.D.G. IT SSH containers have a considerable data stored in environmental variables e.g.:

• MYSQL_USER

• MYSQL_PASSWORD

These can be accessed directly in scripts (e.g. mysql -u $MYSQL_USER -p$MYSQL_PASSWORD) or displayed by running printenv.

File system

Files that require persistent storage are differentiated from application code that changes from deployment to deployment. The files and directories that need to be persistent across deployments are stored in /var/www/html/shared and symlinks to these files or directories are created within /var/www/html/codebase. You can see the symlinks in the SYMLINKS variable in the repository being deployed when using M.D.G. IT pipelines from Gitlab, Bitbucket, etc.

Users and permissions

Containers launch in unprivileged user space with a randomised user ID. This is one of several built in protections that isolate containers. Because containers, including those providing an SSH shell, launch with one user, commands such as su and sudo are not available.

Monitoring

Extensive monitoring is available for each component of the webstack and can be viewed in the OKD console. Because any shell session within the environment will be running on a single container, command line resource monitoring tools such as top do not provide useful information about resource limits or the environment as a whole.

On request, monitoring tools such as New Relic can be installed to provide additional monitoring and debugging.

Restarting services

There is generally little need to manually restart services in Kubernetes, since a failed health check will automatically restart unhealthy containers and upgrades take place using rollouts. There are however situations where rolling out a new set of containers for a particular service is necessary, such as when restarting PHP-FPM to definitively clear the OPcache. To facilitate this from CLI, the following commands are available:

• restart-apache

• restart-php

• restart-mysql

• restart-redis

• restart-varnish

• restart-elasticsearch

Connecting to services

Services are generally not available on localhost as they are when running e.g. MySQL or Redis on the same server. Instead, components talk to each other over a private network. Containers can scale up or down, restart and exist in sets where multiple containers together provide a service like PHP-FPM. Kubernetes uses internal DNS to resolve service names to the IP address of the pods currently responding to requests for a given service. The default service names for common webstack components in M.D.G. IT Managed Kubernetes are:

• MySQL, MariaDB: mysql

• Redis: redis

• Elasticsearch, Opensearch: elasticsearch

• RabbitMQ: rabbitmq

As an example, if you were to make a curl request to Elasticsearch, this would take the form of curl -X GET "elasticsearch:9200/?pretty"

Flushing environment caches

Varnish

In the case of Magento, application configuration files are updated by M.D.G. IT support so that application cache flushing mechanisms work as expected. For other applications, or to definitively clear the Varnish cache completely by restarting the service, please run restart-varnish in SSH.

OPcache

For PHP applications, OPcache can be configured to look for file changes after a predetermined period and update its cache if a file has changed, or to simply read a file once and then serve precompiled code from cache until it is restarted. The latter makes sense on environments where code is not expected to change, such as Fully containerised hosting with embedded code. Appropriate cache settings are implemented during environment design and setup, however please contact support if you need a specific configuration.

If changes to PHP files on block storage are not reflecting on the frontend, consider that this can be caused by OPcache serving files from a stale cache. While OPcache can be cleared programmatically, this is likely to lead to unexpected results on environments where multiple PHP containers are running, since each will have its own cache. For this reason running restart-php is recommended in order to definitely clear the PHP cache.

Mail

We recommend using an SMTP provider to increase deliverability and track delivery and bounces. Recommended services are: AWS SES, Sendgrid, Mailgun, Resend. Alternatively you can connect to your existing corporate email provider.

With multiple containers needing to send mail, SMTP mail transport can be configured directly within your application, or you can provide M.D.G. IT support with credentials to configure a local MTA which any application or service can use to send mail.