Hackathon DevOps 101(blog.devpost.com)
blog.devpost.com
Hackathon DevOps 101
http://blog.devpost.com/post/114493741397/hackathon-devops-101
6 comments
That is true, but that is only a small part of the usefulness of ngrok. It can tunnel TCP port, assigning you a random high-numbered port at their end (like with ssh -R).
But if you are tunneling an HTTP service, you can be assigned a random hostname (random.ngrok.com), or you can request a specific hostname (pkaeding-test.ngrok.com), and your service will be available over both HTTP (port 80) and HTTPS (port 443) on that hostname. This can be critical for testing webhook callbacks where the remote service only allows HTTPS on port 443.
Also, when you are tunneling HTTP services (using HTTP or HTTPS), ngrok will start a web UI running at localhost:3030, detailing all incoming requests. You can examine the headers and body from both request and response, and even replay requests. This is immensely helpful when debugging webhooks.
(I am not affiliated with ngrok, except as a happy user.)
But if you are tunneling an HTTP service, you can be assigned a random hostname (random.ngrok.com), or you can request a specific hostname (pkaeding-test.ngrok.com), and your service will be available over both HTTP (port 80) and HTTPS (port 443) on that hostname. This can be critical for testing webhook callbacks where the remote service only allows HTTPS on port 443.
Also, when you are tunneling HTTP services (using HTTP or HTTPS), ngrok will start a web UI running at localhost:3030, detailing all incoming requests. You can examine the headers and body from both request and response, and even replay requests. This is immensely helpful when debugging webhooks.
(I am not affiliated with ngrok, except as a happy user.)
Yeh true. But what I do in those scenarios is hack up an ngnix config with a (self-signed) wildcard certificate and map certain ports to https endpoints on certain subdomains using ngnix reverse-proxy stuff.
So I expose :9000 on the remote host, and then map :9000 to blah.my.website.com:443 using ngnix
So I expose :9000 on the remote host, and then map :9000 to blah.my.website.com:443 using ngnix
Yeah, that definitely works as well, and it is also what I did before I found ngrok. It is a few more hoops to jump through in order to get things flowing, though, and you don't get the introspection/replay functionality. You can use wireshark to inspect the traffic, I suppose, but again, it isn't as easy.
A lot of people I've worked with at hackathons didn't have a server running so being able to use ngrok is a lot easier for them.
Seems like this post is less about real hackathon strategies for devops, and more about marketing for ChallengePost's (I guess DevPost now?) partners.
It may very well be. But does it matter? As a hackathon organizer/mentor, these are exactly the resources I'd recommend. Publicity by providing a service is not a new concept; I really enjoy this post about it in particular:
http://blog.crew.co/how-side-projects-saved-our-startup/
http://blog.crew.co/how-side-projects-saved-our-startup/
I don't think that post is the same situation at all - there, Crew made side projects that became popular and then received traffic from them. Here, corporate sponsors skew which tools a ChallengePost employee recommends for hackers - some of which I personally believe are not at all good tools for the listed jobs (S3 for static website hosting??).
OP here. Some of the tools are related to clients / hackathon sponsors - but most aren't. And s3 is an excellent tool for static site hosting. You can add cloudfront in a snap, it's stupid cheap, and you can deploy from the command line ( https://github.com/laurilehmijoki/s3_website is awesome for this.)
Also, I've actually used _all_ of these tools before, both for personal & hackathon projects. I know they work.
Also, I've actually used _all_ of these tools before, both for personal & hackathon projects. I know they work.
Chef and test-kitchen to automagically test your recipes in the cloud. VirtualBox and the snapshot creation tool to revert changes to your preferred state while testing recipes in seconds.
The dokku app on Digital Ocean is really good for this.
I'd probably go with IBM Blue Mix or Heroku if digital ocean wasn't sponsoring. No reason to spend time on managing your server at this point and they provide pretty much the same capabilities for the developer deploying code
If you choose the preconfigured app, the setup is essentially adding an SSH key.
https://www.digitalocean.com/community/tutorials/how-to-use-...
https://www.digitalocean.com/community/tutorials/how-to-use-...
Do you have to set up DNS or anything like that?
Other than that, you also need to use or run your own DB or use a hosted solution. That can also be done by a script, but even spending 30 minutes setting up a server and a db is a lot of time when you have a matter of hours to start and demo a project.
Other than that, you also need to use or run your own DB or use a hosted solution. That can also be done by a script, but even spending 30 minutes setting up a server and a db is a lot of time when you have a matter of hours to start and demo a project.
But, why not just run then on your local machines? 99% of the hackathon project never gets updated afterwards anyway
Getting a quick ipage domain and the services they offer is my go to technique.
I've used iPage before. They were down pretty regularly every day for me. So much so, that I abandoned it after less than a week. I've since moved to a Digital Ocean server and Namecheap for domain registration, and I've never looked back.
I have several sites with them and have never had an issue. How long ago was this?
It's admittedly been two or so years, so their infrastructure may have undergone some real revision.
ssh -R 9000:localhost:4200 my.server.is.awesome.com
Boom, your local server is reachable on my.server.is.awesome.com:9000
It's actually quite a useful trick that I use when needing to test integration with 3rd parties when on the dev branch of our API code.
If you like these kind of tricks. I'd really advice watching this talk. https://vimeo.com/54505525