As forem is maturing further and further and I am wondering that once some kind of 1.0 release is reached whether it would not make sense to also create a HELM chart for forem so one can easily deploy a new instance on their existing or new kubernetes cluster. There is already docker support for the platform, it might be necessary to make the docker images production ready instead of just using them for development but doing so would allow an easier deployment process with kubernetes HELM charts and also easier migrations as they can also be specified in helm to occure without or very little downtime.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (6)
We actually are using containers to run forem.dev right now in production. The containers are about as production ready as they can be right now.
The main reason why we are not focusing on running Forem on Kubernetes is due to the operational overhead and costs of using it is pretty high. I would argue that most self hosted users need Forem to be run as cheaply and easily as possible. They don't need a highly available kubernetes cluster to fit their community needs.
We want to enable as many users to run Forem on their own easily and securely. If we focused on supporting the most complex and expensive methods for running software online, that would be a pretty big barrier for a lot of people to overcome. Instead we are starting with the basics by running Forem in containers on a VM. Using containers gives us the flexibility to keep things as modular as possible and support more complex setups (like k8s) down the road. Using VMs is also very cheap and easy for most people that want to self host Forem.
I just don't think k8s the best path to enable most of our self hosted users to get started with Forem right now. Long term, I guess maybe we should have an official method for running on k8s if it helps enable users to run Forem on their own. Personally I am am a pretty big fan of the Operator Framework over Helm. If we had a burning need for getting Forem running on k8s, I think I would create an Operator to get that going.
I totally get why you wouldn't want to focus on this out of the gate and agree that Helm isn't necessarily the best option even if you are providing K8s installation artifacts. But I wouldn't write this off so readily...
There may be classes of users you're not considering here.
For those using managed Kubernetes having to provision and manage raw VMs for this might actually impose higher burdens and cost.
I personally would be way more likely to deploy Forem to one of my existing clusters (especially if its just a
kubectl applyaway) to kick the tires than I would be to provision EC2 instances specifically for it.It's not written off at all Tim. Installing Forem to Kubernetes is a valid use case for a percentage of people that have access to a working cluster and I think we should support something down the road. What I am arguing is that most people do not have such access or understanding of operating code on k8s. Not to mention Kubernetes based deployments are total overkill for most users and use cases.
It's just a matter of providing the biggest impact in the shortest amount of time users that want to self host Forem. VMs with Containers is the path we picked. Pretty boring I know... :)
We're a small consulting shop, and we use Kubernetes because it's cheaper to share infrastructure between our clients than is it to launch a dedicated instance per project with bespoke infrastructure. It would definitely be more complex and expensive for the communities we manage to use a custom Ansible setup than it would be to use a helm chart, and managed Kubernetes is very easy to launch on Digital Ocean, and relatively easy on other providers. Do you have a lot of communities using Forem that have knowledge of how to maintain Ansible but not Kubernetes? These days, I find managing a cluster much simpler, and I think many other small community hosting providers would too.
I'd be happy to write the helm chart up myself and share it with the community, but right now I can't find guidelines in your self hosting doc for how I could use containers for anything but running it locally. Are the containers in the docker-compose file the same ones I should be using in production? If not, are there other guidelines for which containers should be used and how they should be hooked up?
I'll punt this to @jdoss for most relevant opinion. :)
kompose.io/ Provides a very straight forward way to migrate
docker-compose.ymlto k8s resources.