朋友要GitLab，我给了他150MB的替代方案

周三下午，一个朋友发来链接：GitHub可能在俄罗斯被封锁，问我能不能搭个GitLab。我回了两个字：不用。

不是不想帮忙，是看过GitLab的文档之后，我直接关了页面——起步就要4GB内存。我们那台服务器上本来就跑着项目，GitLab上去能把所有资源吃干抹净。

我提了另一个方案：这个工具大学黑客马拉松用过，轻量，闲置时大概150MB内存。朋友没犹豫，同意了。

部署跑着的时候，我随口问了句他怎么同步Obsidian笔记。答案很朴素：WebDAV，没什么特别的。反正服务器端口已经开了，顺手把Nextcloud也扔了进去。一个半小时后，git托管和云存储都有了。

为什么不是GitLab

4GB只是启动需求。我们的服务器没有专职给git，现有项目还在跑。GitLab上去等于宣告其他服务死刑。

替代方案的内存占用是150MB级别。Actions兼容GitHub Actions语法，现有工作流搬过来不用重写。这些我之前在黑客马拉松验证过，知道能跑。

第一次正经用Helm

第一次碰Kubernetes是大四，为了课程成绩部署项目。手写manifest——Deployment、Service、Ingress、PVC，循环往复。知道Helm存在，但没动力学。

这次被迫上手。体验像pacman，但是给Kubernetes用的。一个values.yaml替代五百行YAML，一条命令全起。按老办法做我会疯。

但Helm一开始连集群都看不到：

Kubernetes cluster unreachable: Get "http://localhost:8080/version"

k3s把kubeconfig放在Helm默认不找的地方。解决：

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

echo 'export KUBECONFIG=/etc/rancher/k3s/k3s.yaml' >> ~/.bashrc

轻量git服务部署实录

服务器已有ingress-nginx和cert-manager，配了letsencrypt-prod的ClusterIssuer。DNS提前设好：A记录 git.logiflowadvanced.online 指向 2.27.42.100。

values.yaml核心配置：

ingress启用，指定nginx类，主机名git.logiflowadvanced.online，TLS用gitea-tls密钥，注解挂上cert-manager.io/cluster-issuer: letsencrypt-prod。服务本身配了管理员账号、10GB持久化存储，数据库用单节点PostgreSQL而非高可用版。

执行：

helm repo add gitea-charts https://dl.gitea.com/charts/

helm repo update

helm install gitea gitea-charts/gitea --namespace gitea --create-namespace -f values.yaml

Pod起来了。打开浏览器——证书无效，浏览器报警。

查Ingress：CLASS字段显示。nginx控制器完全忽略了这个Ingress，cert-manager没触发，nginx在拿默认自签名证书应付。

修补：

kubectl patch ingress gitea -n gitea --type=json -p='[{"op":"add","path":"/spec/ingressClassName","value":"nginx"}]'

补丁打完，cert-manager签发证书，站点正常打开。

SSH配置

ssh服务以headless ClusterIP类型创建。需要暴露到外部，改Service类型为LoadBalancer或NodePort，或者走Ingress的TCP/UDP转发。我们选了NodePort，指定高位端口，防火墙放行。

Nextcloud顺手牵羊

Obsidian的WebDAV需求很简单，但Nextcloud能提供更多。同一套Helm流程，values.yaml改改就能上。文件同步、日历、联系人，一次性全解决。