|
| 1 | +# Running Umbraco in Docker |
| 2 | + |
| 3 | +Exactly how you choose to compose your Dockerfile will depend on your project specific needs. This section is not intended as a comprehensive guide, rather as an overview of topics to be aware of when hosting in Docker. |
| 4 | + |
| 5 | +## What is Docker |
| 6 | + |
| 7 | +Docker is a platform for developing, shipping, and running applications in containers. Multiple services exist for hosting these containers. For more information, refer to the [official Docker Documentation](https://docs.docker.com/) |
| 8 | + |
| 9 | +## The Docker file system |
| 10 | + |
| 11 | +By default, files created inside a container are written to an ephemeral, writable container layer. |
| 12 | +This means that the files don't persist when the container is removed, and it's challenging to get files out of the container. Additionally, this writable layer is not suitable for performance-critical data processing. |
| 13 | + |
| 14 | +This has implications when running Umbraco in Docker. |
| 15 | + |
| 16 | +For more information, refer to the [Docker documentation on storage](https://docs.docker.com/engine/storage/). |
| 17 | + |
| 18 | +### General file system consideration |
| 19 | + |
| 20 | +In general, when working with files and Docker you work in a "push" fashion with read-only layers. When you build, you take all your files and "push" them into this read-only layer. |
| 21 | + |
| 22 | +This means that you should avoid making files on the fly, and instead rely on building your image. |
| 23 | + |
| 24 | +In an Umbraco context, this means you should not create or edit template, script or stylesheet files via the backoffice. These should be deployed as part of your web application and not managed via Umbraco. |
| 25 | + |
| 26 | +Similarly, you shouldn't use InMemory modelsbuilder, since that also relies on creating files on the disk. While this is not a hard requirement, it doesn't provide any value unless you are live editing your site. |
| 27 | + |
| 28 | +Instead, configure models builder to use "source code" mode in development, and "none" in production, as [described when using runtime modes](https://docs.umbraco.com/umbraco-cms/fundamentals/setup/server-setup/runtime-modes). |
| 29 | + |
| 30 | + |
| 31 | +### Logs |
| 32 | + |
| 33 | +Umbraco writes logs to the `/umbraco/Logs/` directory. Due to the performance implications of writing to a writable layer, |
| 34 | +and the limited size, it is recommended to mount a volume to this directory. |
| 35 | + |
| 36 | +### Data |
| 37 | + |
| 38 | +The `/umbraco/Data/` directory is used to store temporary files, such as file uploads. Considering the limitations of the writable layer, you should also mount a volume to this directory. |
| 39 | + |
| 40 | +### Media |
| 41 | + |
| 42 | +It's recommended to not store media in the writable layer. This is for similar performance reasons as logs, |
| 43 | +but also for practical hosting reasons. You likely want to persist media files between containers. |
| 44 | + |
| 45 | +One solution is to use bind mounts. The ideal setup, though, is to store the media and ImageSharp cache externally. For more information, refer to the [Azure Blob Storage documentation](https://docs.umbraco.com/umbraco-cms/extending/filesystemproviders/azure-blob-storage). |
| 46 | + |
| 47 | +### Required files |
| 48 | + |
| 49 | +Your solution may require some specific files to run, such as license files. You will need to pass these files into the container at build time, or mount them externally. |
| 50 | + |
| 51 | +## HTTPS |
| 52 | + |
| 53 | +When running websites in Docker, it's common to do so behind a reverse proxy or load balancer. |
| 54 | +In these scenarios you will likely handle SSL termination at the reverse proxy. This means that Umbraco will not be aware of the SSL termination, and will complain about not using HTTPS. |
| 55 | + |
| 56 | +Umbraco checks for HTTPS in two locations: |
| 57 | + |
| 58 | +1. The `HstsCheck` health check - This will result in a failed healthcheck. |
| 59 | +2. The `UseHttpsValidator` - This will result in a build error, if Production runtime mode is used. |
| 60 | + |
| 61 | +To avoid these checks failing, you can remove them in your project. |
| 62 | + |
| 63 | +### Health Check |
| 64 | + |
| 65 | +The health check must be removed via configuration, through the `appsettings.json` file, environment variables, or similar. For more information see the [Health Check documentation](../../../reference/configuration/healthchecks.md). |
| 66 | + |
| 67 | +The `HstsCheck` key is `E2048C48-21C5-4BE1-A80B-8062162DF124` so the appsettings will look something like: |
| 68 | + |
| 69 | +```json |
| 70 | + "Umbraco": { |
| 71 | + "CMS": { |
| 72 | + "HealthChecks" : { |
| 73 | + "DisabledChecks": [ |
| 74 | + { |
| 75 | + "Id": "E2048C48-21C5-4BE1-A80B-8062162DF124" |
| 76 | + } |
| 77 | + ] |
| 78 | + }, |
| 79 | + {...} |
| 80 | +``` |
| 81 | + |
| 82 | +### Runtime mode validator |
| 83 | + |
| 84 | +The `UseHttpsValidator` must be removed through code For more information see the [Runtime mode documentation](runtime-modes.md). |
| 85 | + |
| 86 | +The code to remove the validator can look something like: |
| 87 | + |
| 88 | +```C# |
| 89 | +using Umbraco.Cms.Core.Composing; |
| 90 | +using Umbraco.Cms.Infrastructure.Runtime.RuntimeModeValidators; |
| 91 | + |
| 92 | +namespace MySite; |
| 93 | + |
| 94 | +public class DockerChecksRemover : IComposer |
| 95 | +{ |
| 96 | + public void Compose(IUmbracoBuilder builder) |
| 97 | + => builder.RuntimeModeValidators().Remove<UseHttpsValidator>(); |
| 98 | +} |
| 99 | + |
| 100 | +``` |
0 commit comments