BEFORE YOU START
SECTIONS
Try to use well-maintained images as the foundation for your custom image
Do not hard code any database credentials, or other configuration that requires up front knowledge of the environment. Instead, make all the options configurable as ENV variables that are accessible to an entrypoint script that can configure your application at run time.
See our Wordpress image as an example.
Our entrypoint script takes the database settings from the environment, and configures the wordpress database settings.
Your application will sit behind the ComputeStacks load balancer. This means your application will not have direct access to the real remote address of the visitor. In order to access that data, you will need to read the header X-Forwarded-For.
By default, all docker containers are stateless. This means that the data within the container can go away at any time. To avoid losing data, it's important you define Volumes within ComputeStacks.
ComputeStacks has no awareness of your Dockerfile, therefore volumes defined in your Dockerfile will have no effect. You must define them in ComputeStacks.
To enable SFTP access to your container, you will need to ensure file permissions are set correctly. For this to work, you will need the match the UID/GID of the user in your container, with the user of the SFTP/SSH container. Here is an example from a Dockerfile for our PHP image:
RUN usermod -u 1001 www-data \\\\
&& groupmod -g 1001 www-data
You will also need to make sure you run chown -R on any files added to the container during the build process. This can be done as another RUN command, or as part of your entrypoint script.
You may also want to rest all file/folder permissions with something like this:
find . -type d -exec chmod 755 {} \\\\;
find . -type f -exec chmod 644 {} \\\\;
By default, most images are configured to listen on port 80 with the global load balancer performing SSL offloading on your behalf. In this situation, your app may not realize that the user is connected over SSL and try to redirect them to 443. In this scenario, you will most likely have a redirect error.
To accurately determine the protocol that the user is connecting over, you should look for the HTTP_X_FORWARDED_PROTO header being sent by our load balancer.
Additionally, if you would like to also secure the connection between the application and our load balancer, you can optionally enable the Backend SSL setting in the appropriate ingress rule.
For example, in our Wordpress image, we use:
<?php
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}