It makes me think of how webpack won the builder/packer battle against gulp and grunt by assuming you're building a web app, and want typical web stuff.
Just like you could use gulp to build a C++ app but nearly everybody uses it for the web, you could use Docker for hosting an IRC server but nearly everybody uses it for the web.
But... it didn't. Webpack and Gulp/Grunt aren't even the same category of tool; on a real-world project, you're exceedingly likely to use a build runner like Gulp/Grunt with Webpack (or Browserify).
Webpack is fundamentally a module bundler for non-CommonJS environments; it's not a general-purpose build tool, and isn't really suitable for glueing together any tools that don't directly relate to your browser-targeted bundle. In some projects that's all you need, but that doesn't mean it has somehow "won" from generic build tools - it just tries to solve a different problem.
It doesn't provide a panel, but arguably once you reach a scale where you want to run >1 instances, you're probably going to want to go beyond a default configuration anyway, and use some configuration that's more tailored towards your usecase.
As a point of criticism towards this project in particular: the README makes it sound like it'll magically scale up your application, but it makes absolutely no mention of how to handle state (eg. your database) in that scenario. Spawning new instances (which this project does) is the easy part of scaling, the difficult part is state management and it doesn't address that at all.
As a completely unrelated piece of advice, just because this is mentioned in the README: do not under any circumstances make use of domain registration deals that drop the price for a common TLD like .com below $7 or so. There's a certain fee that the registrar has to pay to the TLD registry per domain, and if the registrar is charging you less than that, that means they're getting the money from somewhere else - often through hidden upsells, exorbitant renewal fees, convoluted transfer systems that try to lock you in, or other customer-hostile schemes.
Caddy is a server which is equivalent of nginx part in Captain. It's orange and apple. Arguably, I can replace the nginx part with Caddy. But captain has more to offer, like building pipeline and scaling.
Great point about customization! I'll add more hooks in the future to account for non-standard nginx configurations.
Finally, Captain doesn't support persistent data, i.e. database. Therefore, scaling up apps is much easier. But my plan is to support this in the future.
PS: Thanks for the heads up about the domain deals. I might have got scammed badly then :/
The problem is that these aren't generalizable problems. Scaling requirements are going to vary depending on the project, also because of the state management issue I mentioned. This, in turn, means that the only projects you can scale with an out-of-the-box approach like this, are those that don't need to scale (horizontally) in the first place. You therefore get little to no added real-world value from these 'scaling' features.
I should point out that this isn't a problem just with your project; I've noticed a general tendency around Hacker News circles to overengineer for 'scaling' (which usually refers specifically to horizontal scaling), trying to invent magic scaling solutions that work for everybody (which don't exist), and completely ignoring that distributed systems are hard and you usually want to scale vertically first.
This problem is compounded by the fact that most applications don't actually need to scale horizontally, since they never get big enough to require it. This means that reviews of such 'magical scaling' tools are almost universally positive, because everybody is reviewing them based on the claimed benefits, not based on real-world experience with scaling requirements. This results in a feedback loop of recommendations for completely ineffective scaling strategies by people who never actually needed them.
> Great point about customization! I'll add more hooks in the future to account for non-standard nginx configurations.
While this would seem to improve the project when viewed in isolation, it's important to realize that you're very likely to fall into the trap of non-generalizable problems.
A lot of monolithic frameworks actually have this issue; they try to provide generic implementations for problems that just aren't generalizable (because they vary too much by project, such as "content management"), and in the process they end up providing hundreds or thousands of different configuration options and hooks... to a point of complexity where it would've been easier and more reliable to just not use the framework at all. A typical example of this are general-purpose CMSes, which are almost inevitably unreliable, messy and insecure.
There's a serious risk of that happening here as well, if you start adding support for more customized setups; at some point, you're going to reach the stage where the complexity of your configuration options exceeds that of the tools you're using behind the scenes (nginx, Docker, etc.). I suppose that'd be a form of the inner-platform effect, too.
I don't mean to discourage you here, but your current approach is very likely to result in something that tries to do a lot of things and none of them particularly well; not because you're implementing it wrong, but because this particular set of features just isn't generalizable as such. You'd probably get better results by providing a collection of tools (and documentation!) for different tasks, that 1) can be used independently, and 2) don't require full control over the infrastructure configuration.
> Finally, Captain doesn't support persistent data, i.e. database. Therefore, scaling up apps is much easier.
I don't agree that "scaling up apps is much easier" - state isn't something that's optional, pretty much any real-world project (especially those that have to scale beyond one instance!) has to persist state of some sort. There's only the choice of whether the tooling supports it, or doesn't. I'd consider it dangerous to present something as magically scalable without addressing this issue; it's bound to result in people having state consistency issues.
Don’t get me wrong. I don’t have anything against Node. Hell, I use it on a daily basis. But I wouldn’t run a Node based server and expose it to the internet. That’s a bit too high risk for me.
Well done then!
2. Even with Nginx, you would have two different Docker containers (one with Nginx and one without).
3. And even if I had different container files: For a ideal cluster you need min. 3 managers (and in a perfect world another external load balancer before them or just a DNS with multiple A records to all managers (in case one manager drops)). Then, even if they run Nginx you need to sync the Letsencrypt stuff somehow.
Regarding the Letsencrypt (LE) and Certbot SSL renewal and why it's not simple: LE makes a know-well request to check your credentials every three months and because every node could and should be able to answer this request you have to make sure that all nodes have the same knowledge (either through secrets or through filesync or the underlying host OS of the front-facing server takes care of this).
[0] https://github.com/githubsaturn/captainduckduck/blob/master/...
I am so glad that someone actually found it useful :)
How does it compare with UCP ?
Captain to UCP is like a Honda Civic to a Ferrari :P Surely I would use UCP for an Enterprise grade if i have the money for learning investment, management and all the "enterprisy" cost that comes with it. Captain is written by a one bored guy on weekends in 3 months. UCP is written by a solid Enterprise.
A small suggestion - maybe show a GIF with a few screens from the app instead of a video? So that when someone opens the repo he gets a little preview of whats inside?
Original text: I'm not the target market at all, but it's hard to trust a project that relies on Docker but doesn't have the Docker configuration in the repo.
Will you also add a database?
If you want to the slightly harder way (with less moving pieces), I highly recommend docker-compose + traefik (does the LE and proxying and subdomain) and a learning how to create a simple dockerfile either of the languages.
Great job on the name!
