A Helm chart was actually where I started down that road. I was using Helmfile to define the stack all in one place to install the Helm charts for the Postgres and Redis (and Elasticsearch back when it was still part of the stack) instances in addition to the Rails app. It worked really nicely.
I am also using Argocd for GitOps. I honestly think dev.to should tap into kubernetes, it will become easier to manage this project. Plus attract more enterprise customer.
Still doing some configuration. But this is really working well.
All of the secrets are hard coded at the moment. But I think I can use vault chart to deploy hashicorp vault and fetch the secrets from vault.
Correct. We removed it in favor of using Postgres full-text search because a JVM running Elasticsearch consumed more memory than the entire rest of the stack combined on a self-host instance.
I am using some other operator to manage each component separately.
Nice. That looks very much like where I landed, too. I don't have imgproxy running, but I should. Serving raw images can give away sensitive personal information (name and time/location the photo was taken) when they're uploaded to the Forem instance from a phone and imgproxy strips that out.
Running into couple of issue with my deployment, exactly not sure what is causing it, I wonder if you are seeing something similar with your deployment, when you have time possible to go through this issues.
A Helm chart was actually where I started down that road. I was using Helmfile to define the stack all in one place to install the Helm charts for the Postgres and Redis (and Elasticsearch back when it was still part of the stack) instances in addition to the Rails app. It worked really nicely.
Actually I am working on this project since yesterday :). I manage to deploy dev in kubernetes. Its running on baremetal from my home.
goglides.dev/
I am using some other operator to manage each component separately.
github.com/ot-container-kit/redis-... (for redis management)
postgres-operator.readthedocs.io/e... (for postgres)
github.com/imgproxy/imgproxy-helm (for image proxy)
cert-manager.io/docs/configuration... (to automate certificate management)
kubernetes.github.io/ingress-nginx... (for ingress)
operatorhub.io/operator/elastic-cl... (for elasticsearch)
rancher (for kubernetes)
github.com/openshift/local-storage... (for storage management)
I am also using Argocd for GitOps. I honestly think dev.to should tap into kubernetes, it will become easier to manage this project. Plus attract more enterprise customer.
Still doing some configuration. But this is really working well.
All of the secrets are hard coded at the moment. But I think I can use vault chart to deploy hashicorp vault and fetch the secrets from vault.
Wait a minute are you saying Elasticsearch is now not a part of stack ?
"(and Elasticsearch back when it was still part of the stack)"
Correct. We removed it in favor of using Postgres full-text search because a JVM running Elasticsearch consumed more memory than the entire rest of the stack combined on a self-host instance.
Nice. That looks very much like where I landed, too. I don't have imgproxy running, but I should. Serving raw images can give away sensitive personal information (name and time/location the photo was taken) when they're uploaded to the Forem instance from a phone and imgproxy strips that out.
Running into couple of issue with my deployment, exactly not sure what is causing it, I wonder if you are seeing something similar with your deployment, when you have time possible to go through this issues.
issue fixed forget to tun
bundle exec sidekiq -c 2