Live data from Hacker News

Runnable Sandboxes: Full-stack environments for every GitHub branch

blog.runnable.com

31–40 of 56 posts

Re: Runnable Sandboxes: Full-stack environments for every GitHub branch

#31
post #2

Hey All - Founder here. Happy to answer any questions or discuss some of the problems we've solved building on Docker.

Do the stacks run with Docker Swarm and Docker Networking? If so, does it work well? Any strange issues you had to work around, etc?

Re: Runnable Sandboxes: Full-stack environments for every GitHub branch

#33
post #28
post #14

Earlier quoted context omitted.

We're trying to hire developers to help us do that :-)

What's your stack like? For those interested...

Our stack is comprised of 15 stateless micro services all built with Nodejs. MongoDB, Redis and Neo4j are used for persistence, caching, and dependency management. The fundamental piece our system is RabbitMQ which is used as our event queue. The architecture designed around events. When an application dies or a commit is made, an event propagated through the system.

We also use a lot of open source software. Docker Machines + Swarm is used to schedule and run applications. Docker Registry is used to store images. We use WeaveWorkes weave for inter-container communication.

We are starting an engineering blog as well, keep posted for deep dives into our architecture! http://blog.runnable.com/

Re: Runnable Sandboxes: Full-stack environments for every GitHub branch

#34
My company build something pretty identical to this a few years ago. It's INVALUABLE if you have a QA team or non-tech people who need to test things on different branches. Our workflow basically went like this:

1. Dev pushes branch to repo 2. Dev assigns ticket to QA 3. QA builds a sandbox server 4. QA tests everything under the sun 5. Any bugs are pushed to repo and auto-pushed to sandbox server 6. After QA gives green light, sandbox server is taken down.

Average uptime for a sandbox server was a few hours, and we caught a bazillion bugs this way. I'm no longer with that company, so it's really exciting that someone else has built something like this off-the-shelf so that I can continue with that workflow at future jobs. :)

Re: Runnable Sandboxes: Full-stack environments for every GitHub branch

#35
post #31
post #2

Hey All - Founder here. Happy to answer any questions or discuss some of the problems we've solved building on Docker.

Do the stacks run with Docker Swarm and Docker Networking? If so, does it work well? Any strange issues you had to work around, etc?

Our stack does use swarm under the hood. So far we have not seen any major issues with scheduling across 100 servers. However we have seen issues with the swarm event stream disconnecting. Our workaround was connect to the event stream of the docker engines directly and use the `since` parameter. We currently use weave net to handle docker networking and have not had major issues with it.

Re: Runnable Sandboxes: Full-stack environments for every GitHub branch

#36

My company build something pretty identical to this a few years ago. It's INVALUABLE if you have a QA team or non-tech people who need to test things on different branches. Our workflow basically went like this: 1. Dev pushes branch to repo 2. Dev assigns ticket to QA 3. QA builds a sandbox server 4. QA tests everything under the sun 5. Any bugs are pushed to repo and auto-pushed to sandbox server 6. After QA gives g…

Founder here. Check us out for your future jobs. Maintaining sandbox infrastructure is a pain.

One of our key lessons is being able to dispose and rebuild your infrastructure on a daily or weekly basis so leaks don't destroy your environment.

We recycle customer environments in Runnable, on a regular basis and its completely transparent to users

Re: Runnable Sandboxes: Full-stack environments for every GitHub branch

#38
post #28

Earlier quoted context omitted.

What's your stack like? For those interested...

Our stack is comprised of 15 stateless micro services all built with Nodejs. MongoDB, Redis and Neo4j are used for persistence, caching, and dependency management. The fundamental piece our system is RabbitMQ which is used as our event queue. The architecture designed around events. When an application dies or a commit is made, an event propagated through the system. We also use a lot of open source software. Docker…

What is your experience with using Docker Swarm in a production environment? I have heard conflicting views regarding it.

Re: Runnable Sandboxes: Full-stack environments for every GitHub branch

#39

Looks like exactly what we're looking for. Why is it only available with a Github organization account though?

Support for other code repositories is on our roadmap — we are looking to hire more developers to help build support for them ! :)

Re: Runnable Sandboxes: Full-stack environments for every GitHub branch

#40

This is really cool. Can you explain if I would use this instead of my Jenkins server, or in addition to my Jenkins server?

You might be able to replace Jenkins :-). Runnable builds every branch as soon as it's updated with a push, and then deploys it. This allows you to spin off branches for your app and use/test them in a matter of seconds. Builds are exportable as Docker images which are stored in an authenticated registry.

Would love to hear what your use-case is and whether it's a good for or not! Send me an email jorge@runnable.com

Post reply on HN