Auto-update blog content from Obsidian: 2026-02-02 19:55:52
All checks were successful
Blog Deployment / Deploy-Staging (push) Successful in 9s
Blog Deployment / Test-Staging (push) Successful in 2s
Blog Deployment / Check-Rebuild (push) Successful in 5s
Blog Deployment / Build (push) Has been skipped
Blog Deployment / Merge (push) Successful in 6s
Blog Deployment / Deploy-Production (push) Successful in 9s
Blog Deployment / Test-Production (push) Successful in 1s
Blog Deployment / Clean (push) Has been skipped
Blog Deployment / Notify (push) Successful in 2s
All checks were successful
Blog Deployment / Deploy-Staging (push) Successful in 9s
Blog Deployment / Test-Staging (push) Successful in 2s
Blog Deployment / Check-Rebuild (push) Successful in 5s
Blog Deployment / Build (push) Has been skipped
Blog Deployment / Merge (push) Successful in 6s
Blog Deployment / Deploy-Production (push) Successful in 9s
Blog Deployment / Test-Production (push) Successful in 1s
Blog Deployment / Clean (push) Has been skipped
Blog Deployment / Notify (push) Successful in 2s
This commit is contained in:
@@ -1,11 +1,17 @@
|
|||||||
---
|
---
|
||||||
slug:
|
slug: how-I-deploy-application
|
||||||
title: Template
|
title: How Do I Deploy Application Today
|
||||||
description:
|
description: The method I use today to deploy new application in my homelab. Simple workflow taking advantage of Docker Compose in a VM on Proxmox VE
|
||||||
date:
|
date: 2026-01-31
|
||||||
draft: true
|
draft: true
|
||||||
tags:
|
tags:
|
||||||
|
- docker
|
||||||
|
- proxmox
|
||||||
|
- opnsense
|
||||||
|
- treafik
|
||||||
|
- gitea
|
||||||
categories:
|
categories:
|
||||||
|
- homelab
|
||||||
---
|
---
|
||||||
## Intro
|
## Intro
|
||||||
|
|
||||||
@@ -27,17 +33,17 @@ I have been using Docker Compose for years. At the time, everything was running
|
|||||||
|
|
||||||
For now, I still rely on a single VM to host all Docker applications. This VM is more or less a clone of my old physical server, just virtualized.
|
For now, I still rely on a single VM to host all Docker applications. This VM is more or less a clone of my old physical server, just virtualized.
|
||||||
|
|
||||||
### Proxmox
|
### Proxmox VE
|
||||||
|
|
||||||
All my VMs are hosted on a Proxmox cluster.
|
This VM is hosted on a Proxmox VE cluster, composed of three nodes and uses Ceph as a distributed storage backend.
|
||||||
|
|
||||||
The cluster is composed of three nodes and uses Ceph as a distributed storage backend. This gives me high availability and makes VM management much easier, even though the Docker workloads themselves are not highly distributed.
|
This gives me high availability and makes VM management much easier, even though the Docker workloads themselves are not highly distributed.
|
||||||
|
|
||||||
### Traefik
|
### Traefik
|
||||||
|
|
||||||
Traefik runs directly on the Docker host and acts as the reverse proxy.
|
Traefik runs directly on the Docker host and acts as the reverse proxy.
|
||||||
|
|
||||||
It is responsible for routing HTTP and HTTPS traffic to the correct containers and for managing TLS certificates automatically using Let’s Encrypt. This keeps application-level configuration simple and centralized.
|
It is responsible for routing the HTTPS traffic to the correct containers and for managing TLS certificates automatically using Let’s Encrypt. This keeps application-level configuration simple and centralized.
|
||||||
|
|
||||||
### OPNsense
|
### OPNsense
|
||||||
|
|
||||||
@@ -126,24 +132,32 @@ Most of the time, updates are straightforward:
|
|||||||
- Check Docker logs
|
- Check Docker logs
|
||||||
- Test the application to detect regressions
|
- Test the application to detect regressions
|
||||||
|
|
||||||
If everything works, I continue upgrading step by step until I reach the latest available version. Once done, I commit the changes to the repository.
|
If it works, I continue upgrading step by step until I reach the latest available version.
|
||||||
|
|
||||||
|
If not, I debug until I fix the problem. Rollbacks are painful.
|
||||||
|
|
||||||
|
Once the latest version is reached, I commit the changes to the repository.
|
||||||
|
|
||||||
---
|
---
|
||||||
## Pros and Cons
|
## Pros and Cons
|
||||||
|
|
||||||
|
What works well and what doesn't?
|
||||||
|
|
||||||
### Pros
|
### Pros
|
||||||
|
|
||||||
- Simple model, one VM, one compose file per application.
|
- Simple model, one VM, one compose file per application.
|
||||||
- Traefik automates TLS and routing with minimal boilerplate.
|
- Easy to deploy, great to test an application.
|
||||||
- Everything declarative enough to rebuild quickly from the repo.
|
- Central location for the configurations.
|
||||||
- Easy to debug: logs and Compose files are local and transparent.
|
|
||||||
|
|
||||||
### Cons
|
### Cons
|
||||||
|
|
||||||
- Manual updates don’t scale as the app count grows.
|
|
||||||
- Single Docker VM is a single point of failure.
|
- Single Docker VM is a single point of failure.
|
||||||
- Secrets in .env are convenient but basic; rotation and audit are manual.
|
- Manual updates don’t scale as the app count grows.
|
||||||
- No built‑in rollbacks beyond “change the tag back and redeploy.”
|
- Having to declare the URL on Caddy is boring.
|
||||||
|
- Hard to follow what is up, and what is not.
|
||||||
|
- Secrets in .env are convenient but basic.
|
||||||
|
- No fast way to rollback.
|
||||||
|
- Operations on the VM are critical.
|
||||||
|
|
||||||
---
|
---
|
||||||
## Conclusion
|
## Conclusion
|
||||||
Reference in New Issue
Block a user