I know this looks like a trivial question, but I’m not sure if this structure is possible with Docker Composer and Caddy or not.
Sorry if this question looks like a trivial / lazy question a lot.
Since this question is not actually asking about ‘How to configure Caddy?’, I removed the default template for asking question because that template looks like for asking ‘How to configure Caddy?’ to me.
If this structure is possible with Caddy, I will look Caddy documentation more precisely and come back if I face a problem while configuring Caddy.
I want to serve multiple ‘things’(website/database etc.) within single Oracle Cloud instance. It is free tier instance but I think that is enough for this plan.
The reason I used
example.com as domain is I haven’t actually configured my DNS records with all of these subdomains like
website.example.com yet. When I actually configure Caddy, I will first configure my DNS for all of these subdomains will point to same IP address with A type. (My DNS provider doesn’t support DDNS)
Here is brief concept of my plan in form of image.
There were two images, but I can only post one image for now.
In below, there are same contents in text form, with more detailed description.
I want to serve these five ‘things’ with Docker Compose and use Caddy as ‘gatekeeper’.
Caddy will redirect every traffic to each of sibling containers depending on what subdomain that client accessed with.
For example, if client accessed with
db.example.com, the traffic will be redirected to ‘Database’ container. Client won’t be able to access other containers with that subdomain.
With Caddy, I can automatically enable HTTPS for all of my websites and I really like that.
Since Caddy is the only thing that interacts with Internet, client can’t directly access other containers!
All sibling containers will communicate with HTTP, not HTTPS. (TLS Termination Proxy)
The database will be PostgreSQL. I will change default port from
5757 because of security.
I’m not sure, but if I remember correctly, all sibling containers still be able to access Database with default
5432 port, even though I change it with Docker Compose.
Since I need to access Database from another machine, I must open port of Database to public.
I want to host static webpages made with Hugo and Gitea will host its ‘source code’.
The reason why I want to use Gitea is, I think the repository’s size will exceed 5GB which is limit of GitHub repository.
Since webpage will contain a lot of images, even though I convert them to WEBP image for file size reducing, the repository’s size will exceed 5GB. Gitea is self-hosted so I guess it doesn’t have such limit.
I need a ‘safer place’ that I can save ‘source code’ of my website, safer than my local hard drive.
I also want to provide myself a Link Shortening Service. I know there are a lot of service of this kind like b**.ly, but I want my shortened link managed by myself. Many of those kind of service limits ability of managing shortened link without paying to them.
I know Gitea doesn’t provide ‘Gitea Pages’ yet. I think I must make a script that generates static website when I push to Gitea repository.
My plan is, when Gitea Push event happens, it will generate static webpage with Hugo and serve it to public.
Or I can just generate static webpages locally and push it to another branch, and make this container ‘pulls’ website from Gitea repository and serve it.
I also want to host another website. Maybe this would be written with Node.js or PHP. Its source code will be hosted on GitHub private repository, but website will be hosted in this container.
This is my plan and I really want to know if this plan is possible or not. I’ve tried to use NGINX first, but I got lost in a maze of NGINX configuration.
I’m not sure if I should provide ‘previous’ Docker Compose YAML configuration file’s content because this is partially tested with Docker Desktop (Windows) and I have to use it on Oracle Cloud (Linux). I used NGINX for this test too.
If you want to see that ‘old’ Docker Compose YAML configuration file, tell me. I will append its content below.
Thank you for reading this long story.