Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

gitlab.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

#51

Post by derfabianpeter »

filmgirlcw wrote: post #18
gavinray wrote: post #11

This looks incredible! Has some serious offerings against the current Self-Hosted PaaS scene, hope I can check it out over the weekend. I have used Dokku[0] in production, and played with CapRover[1] on hobby projects. Flynn was like a better Dokku, before development died.[2] CapRover is a great experience, and it's not a toy IMO. It nails the role of "I want to press a button and have a self-hosted Heroku, with a n…

Agreed with all of this. The other option I would mention, although it has a wonky pricing structure is Cloudron [1]. I use CapRover on a spare droplet and it’s a really good solution. This looks like a compelling option too. [1]: https://www.cloudron.io/

Author of apollo here. Using multiple Cloudron instances for production stuff and am still heavily inspired by the operational stability and ease of app-onboarding the Cloudron team has managed to maintain. apollo strives to deliver a Cloudron-like experience (in terms of stability) over time.

Re: Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

#52

Post by gavinray »

derfabianpeter wrote: post #46
gavinray wrote: post #11

This looks incredible! Has some serious offerings against the current Self-Hosted PaaS scene, hope I can check it out over the weekend. I have used Dokku[0] in production, and played with CapRover[1] on hobby projects. Flynn was like a better Dokku, before development died.[2] CapRover is a great experience, and it's not a toy IMO. It nails the role of "I want to press a button and have a self-hosted Heroku, with a n…

Hey, author of apollo here. Thanks for the feedback and questions, I'll try my best to shed a little light here. - Yes, you can run apollo even on nodes with only 512MB RAM and 1 core. There's no programmatically imposed limit - it's just an advice to bring beefy infrastructure to production setups as metric-collection/logging consumes quite a lot of memory. You can just use apollo with a 2GB HETZNER node (2,98€/m) a…

Thank you, that does answer everything! I also see now after going through the readme again "Single-node clusters are possible and can be scaled up", so apologies for that question.

Re: Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

#53

Post by gavinray »

koeng wrote: post #32
gavinray wrote: post #11

This looks incredible! Has some serious offerings against the current Self-Hosted PaaS scene, hope I can check it out over the weekend. I have used Dokku[0] in production, and played with CapRover[1] on hobby projects. Flynn was like a better Dokku, before development died.[2] CapRover is a great experience, and it's not a toy IMO. It nails the role of "I want to press a button and have a self-hosted Heroku, with a n…

How would you compare Caprover to Dokku? I use dokku a lot, and really love some of the plugins (like postgres with the automatic backups and such). Is there any reason why you wouldn't use Caprover in production? (other than you haven't needed to)

I was kind of forced into using Dokku in production. I inherited a 4-year old Rails codebase previously running on AWS EC2 and that was how the infra was set up.

But given the timeline, I think it was probably the best available option at the time. Flynn, CapRover, etc weren't really a thing, so Dokku was innovative in this space.

I would say that there's absolutely nothing wrong with Dokku, but experience-wise CapRover is miles ahead.

> Is there any reason why you wouldn't use Caprover in production? (other than you haven't needed to)

If you use the Docker Swarm setup multi-node, I feel like it's a solid choice for a small company. If you get big/complex enough, you'll probably eventually wind up needing k8s/Nomad but as far as tradeoffs for development velocity vs stability, I feel good with CapRover.

Going to try Apollo out soon though. It appears to address things like multiple environments better than CapRover. And as mentioned, the docker-compose.yaml integration is a huge one for me.

Re: Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

#54

Post by gavinray »

sradman wrote: post #39
m3adow wrote: post #37

Is this the first self-hosted PaaS solution also running on Kubernetes? As far as I know neither Dokku nor CapRover do, which always deterred me from these applicationsas I'm running K3s at home.

I assumed that Knative [1] is the canonical self-hosted PaaS for Kubernetes. It is branded as Cloud Run [2] by Google. I'm not sure how it compares feature-by-feature with Dokku nor a 12-Factor App PaaS like Heroku. [1] https://cloud.google.com/knative [2] https://cloud.google.com/run

This is pedantic, but Knative and Cloud Run aren't quite the same thing.

Knative is the "serverless" (bit a weird term in this context) eventing/serving framework, and Cloud Run is a managed Knative service.

You can self-host/install Knative to your k8s cluster and the experience you end up with is pretty PaaS-ey.

Less known is this space is Rio by Rancher Labs, which is also great + similar:

https://rio.io/

Re: Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

#55

Post by gavinray »

zapt02 wrote: post #33
axbytg wrote: post #15

Earlier quoted context omitted.

Looks like the main difference is docker compose compatibility but admittedly I have more reading to do. Still tho that is a good difference! I have multiple caprover nodes in prod for hobby stuff so absolutely not knocking it.

CapRover does support docker-compose. Maybe not as streamlined as some other platforms but you can use it. https://caprover.com/docs/docker-compose.html

I know the docs make it look like it does, but it doesn't really.

What it actually supports is copy + pasting sections of Docker Compose for prebuilt images.

So let's say you have a docker-compose.yaml where one of your services uses "build"/"context" and points to a local Dockerfile. You cannot deploy this to CapRover (in this way, through docker-compose.yaml).

The docker-compose support is more geared towards the "one-click" apps they have when you want to deploy something like pgAdmin or MySQL which uses a prebuilt image.

Because of this, it means you can't really deploy your existing setup. From the instructions:

  1. Navigate to Apps
  2. Click on "One Click Apps/Databases"
  3. Navigate to the very bottom of the list, and click on the last item, called >> TEMPLATE
^^ Because this is happening on your serverside instance, in a web app, it has no context for local files.

The "Alternative Approach" is to connect to your instance and upload the source + manually run "docker-compose up" with it wired to the overlay network. This is not a good or scalable solution IMO.

Re: Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

#56

Post by filmgirlcw »

derfabianpeter wrote: post #51
filmgirlcw wrote: post #18

Earlier quoted context omitted.

Agreed with all of this. The other option I would mention, although it has a wonky pricing structure is Cloudron [1]. I use CapRover on a spare droplet and it’s a really good solution. This looks like a compelling option too. [1]: https://www.cloudron.io/

Author of apollo here. Using multiple Cloudron instances for production stuff and am still heavily inspired by the operational stability and ease of app-onboarding the Cloudron team has managed to maintain. apollo strives to deliver a Cloudron-like experience (in terms of stability) over time.

This is awesome to here! I’m really looking forward to testing Apollo out!

Re: Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

#57

Post by slayerjain »

sradman wrote: post #49
m3adow wrote: post #41

Earlier quoted context omitted.

Isn't Knative for functions & serverless only? That's not my main scenario at home.

If Knative is more self-hosted FaaS than PaaS, that explains the core use case for Apollo; a traditional 12-Factor App PaaS for Kubernetes/Docker-Swarm. Knative supports a Serving Spec for routing (like AWS API Gateway) but doesn't seem to have buildpacks for 12-Factor App frameworks, as far as I can see. Apex Up [1] deploys web apps on top of AWS Lambda using Amazon's API Gateway as the RESTful routing proxy. Maybe…

AWS now also provides native support for deploying 'regular' web apps using lambda + API gateway. I've been using this for my hobby projects - https://github.com/awslabs/aws-lambda-go-api-proxy

Re: Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

#59

Post by throwaway77384 »

dig1 wrote: post #42
throwaway77384 wrote: post #35

How does this compare to Dokku? Been using Dokku for a year now, and it is quite a joy. Admittedly, I'm not in the 1000s of requests per second space that many other people operate in (I'm in the internet equivalent of the Mom & Pop website hoster space). I've found Dokku does everything Heroku does, but I get to control it all, which is really nice. Never tried Caprover or the other container solutions, because I'm…

I've been using Dokku for years, and I have only positive words for it. Here is my experience regarding your questions: - Scaling: Dokku can scale your application (via "dokku ps:scale" command) on the same machine. If you are concerned with spikes, put Cloudflare (free tier) in front, it will solve most of the problems. - Hacking: Dokku will expose Nginx and proxy requests to your application from the public. Assumi…

This is extremely useful information, thank you very much. You have helped me feel more confident about my setup.

Cloudflare free in front: Check

Regularly updated system behind firewall, sound framework: Check

Regular cron-job DB-dumps + daily Hetzner backup + code etc on git: Check

Load balancing: This is a new one to me. Excellent! I had wondered about how to do some kind of two-machine load-balancing and eventually, failover. Still finding it tricky to wrap my head around how I'll keep my DB consistent between the two systems, etc, but so far I'm nowhere near the size where this is needed from a performance perspective. This is about redundancy only, so far.

Very helpful, thank you!

Re: Apollo – An Extensible Docker-Based Platform as a Service (PaaS)

#60

Post by throwaway77384 »

derfabianpeter wrote: post #43
throwaway77384 wrote: post #35

How does this compare to Dokku? Been using Dokku for a year now, and it is quite a joy. Admittedly, I'm not in the 1000s of requests per second space that many other people operate in (I'm in the internet equivalent of the Mom & Pop website hoster space). I've found Dokku does everything Heroku does, but I get to control it all, which is really nice. Never tried Caprover or the other container solutions, because I'm…

Hey, author of apollo here. Unfortunately I've never used Dokku or Heroku myself, but from what I know of them, apollo is different in that it doesn't provide any platform services developers can consume (like DBs, Caches, S3, ...). apollo is explicitly made for production use which is why the focus is on operations and infrastructure and we leave the tooling in the hands of the developer (hence we support native doc…

Ah, thank you for the additional info.

For the time being I am probably not doing anything complex enough to warrant switching away from Dokku.

As a single-person operation, I have to keep a pretty fragile balance between effort-of-setup (I can deal with a bit more effort than Heroku) / control-over-setup (I need Dokku's finer-grained control, with more effort).

One day I may outgrow those requirements, however. Who knows. I will keep Apollo in mind for that :)

Post reply on HN