ddollar

6 ms·

31.
by ddollar 11y ago
Yes, there is a business behind Convox. The founders are all ex-Heroku engineers and have we all have a great deal of experience building this type of tooling and automation. For now we are focused on building a great open-source platform.
32.
by ddollar 11y ago
ECS is working out great for us. We host all of our own internal infrastructure on Convox and have been very happy. The minimum per-application cost would be for an ELB. Counting the slice of runtime cluster needed to run it I'd estima
33.
by ddollar 11y ago
We're strongly considering other clouds but are focused on AWS for the moment.
34.
by ddollar 11y ago
Unless it has changed since I last look Dokku only runs on a single server. The other major difference is that software like Dokku is trying to run anywhere. Because we are only trying to run on AWS we do not need to build custom schedulers
35.
by ddollar 11y ago
Absolutely! You can decide not to use a front-end load balancer. We have one user using Convox to spin up large worker pools on AWS. We also have plans on our roadmap to integrate with internal (inside the VPC only) ELBs for internal APIs a
36.
by ddollar 11y ago
You're quite welcome! All three of the Convox founders are huge proponents of open source. We've already seen the benefit from this as a user has mapped out the missing pieces to host HIPAA-compliant applications on Convox and has
37.
by ddollar 11y ago
It is similar to Deis in goals but it differs substantially in implementation. Because Convox runs on AWS we can rely on stable and scalable services only available on that platform such as ELB and DynamoDB. Deis uses its own internal Postg
38.
by ddollar 11y ago
Hello! I'm part of the Convox core team and happy to answer any questions. Convox is an app deployment platform that you can install into your own AWS account. It uses ECS, ELB, Kinesis, and many other great AWS services under the hood
39.
by ddollar 12y ago
> The selling point behind these devices is convenience, but at the cost of security. I don't think I need to explain to HN why an always-on, internet connected voice recording device is something to keep out of your house. Do you h
40.
Nitrous.IO Box Snapshots(blog.nitrous.io)
2 points by ddollar 12y ago|0 comments
41.
by ddollar 12y ago
I have not found myself needing to change those things very often once I have created the initial Dockerfile. If you've got the time I'd love to hear more about your workflow at david@nitrous.io
42.
by ddollar 12y ago
I'm really excited about the idea of groups that may be coming to Docker. It seems like a great primitive around which to build tools like fig and tug and perhaps other tools to orchestrate production. https://www.youtube.co
43.
by ddollar 12y ago
Sorry about that! I'm trying to get the docs into shape as fast as possible. If a line starts with "docker/" the rest is assumed to be a docker image tag.
44.
by ddollar 12y ago
Thank you for the kind words and the clarifications Mitchell :) Tug is a simple tool that I wrote to scratch a personal itch around working with dockerized applications and trying to optimize for startup speed and writing as absolutely litt
45.
by ddollar 12y ago
Awesome :) I think then that the primary difference with Tug is that it can work in a "hybrid" virtualized/local mode if you haven't yet written a Dockerfile/Vagrantfile/other for your app. Tug can start by sim
46.
by ddollar 12y ago
Nice :) I believe Vagrant also now has built-in support for Docker which is very useful for starting up ancillary services that your app needs: https://docs.vagrantup.com/v2/provisioning/docker.html I quite like V
47.
by ddollar 12y ago
Tug primarily differs from fig in two ways: * Less verbose configuration, tries to assume sensible defaults * Works with apps that do not yet themselves have a Dockerfile
48.
by ddollar 12y ago
Hello everyone! We created tug as a tool to help people dockerize applications and run them during development. Please keep in mind that this is a very alpha project still under heavy development. If you try it I'd love to hear how it
49.
by ddollar 13y ago
There are two reasons I rewrote Foreman in Go. You hit one of them square on the head. A single binary with no dependencies that can be cross-compiled on a Heroku dyno makes things much simpler. Foreman was originally written in Ruby whic
50.
by ddollar 15y ago
Thanks for the feedback! We made the script a link so you could check out what's going on before running it. The heroku-toolbelt .deb actually depends on system git-core and ruby1.9.1 so we shouldn't be trampling anything.
51.
by ddollar 15y ago
San Francisco, CA - Heroku We're looking for an active member of the Node.js community to come own Node.js at Heroku. This position involves both contributing to the Node.js open-source community and working to reduce friction for Node.js u
52.
by ddollar 15y ago
If you try the latest foreman it should be a lot better about killing things off now. See other comments in this thread about the SIGTERM-pause-SIGKILL approach.
53.
by ddollar 15y ago
You could also check out something like http://upstart.ubuntu.com/wiki/Stanzas#limit for use in your upstart scripts.
54.
by ddollar 15y ago
Yes. If you kill foreman with Ctrl-C (or killing its pid externally) it will send SIGTERM to all of the child processes, followed 3 seconds later by SIGKILL to any that haven't terminated yet.
55.
Foreman: Run Complex Apps with Ease(blog.daviddollar.org)
23 points by ddollar 15y ago|2 comments