For those of you who want to see the source code, here is a link to the github repo. Feel free to fork, and do what you like to make it better for you. https://github.com/kencochrane/golang-on-dotcloud
Why do you build in the server instead of cross compiling on the client and pushing a binary? Cross compiling will allow developers to use GOPATH instead collecting all dependencies in a directory tree for upload dotCloud.
I could have done that but, but I decided to build on the server for a few reasons.
1. I wanted to keep this custom service similar to other dotCloud custom services where they build on the server.
2. I didn't want to have to worry about trying to build on the client, there are a lot of unknowns, where as on the server I know what is going on and it is in a controlled environment.
3. I'm still new to Go, and I wanted to keep things as simple as possible to start.
I'm not opposed to doing the cross compiling on the client, I just needed to make a choice, and I picked the server side instead. If I hear from people that it is better to do this on the client, I'd be happy to accept a pull request to change it.
Compiling Go code is super easy; but how easy it is to cross-compile from e.g. OS X to Linux? Or from Windows to Linux? And would there be an advantage over the current situation? (This is a genuinely naive question; I'm fairly new to Go!)
It's not out-of-the-box though. You still have to build Go itself once for each target, so kencochrane is right: it's still easier to rely on dotCloud to build server-side.
You can compile from any OS, for any OS. I compile for 32 and 64 bit versions of Windows, OSX, and Linux for my applications. It takes about 5 seconds for all the builds (running serially) to complete.
I'm still new to Go, so I'm sure there are ways to make this much better, so if you have any suggestions, please let me know. This was done during a hack day, so I know there are improvements that can be made.
Would you say Heroku is big on the vendor lock in too? If you stay away from the ad-ons they are really mostly just running some code and maintaining a standard database unlike say Google App Engine. I don't see how moving to say EC2 or your own servers is really that much work on the grand scale of things and I have done a fair number of data center moves and server migrations etc.
> I was sad to find out that there were not many options for hosting Go applications. It seems you could run your own server (VPS, etc) or you could deploy to Google App Engine.
19 comments
[ 4.2 ms ] story [ 56.8 ms ] thread1. I wanted to keep this custom service similar to other dotCloud custom services where they build on the server.
2. I didn't want to have to worry about trying to build on the client, there are a lot of unknowns, where as on the server I know what is going on and it is in a controlled environment.
3. I'm still new to Go, and I wanted to keep things as simple as possible to start.
I'm not opposed to doing the cross compiling on the client, I just needed to make a choice, and I picked the server side instead. If I hear from people that it is better to do this on the client, I'd be happy to accept a pull request to change it.
It's not out-of-the-box though. You still have to build Go itself once for each target, so kencochrane is right: it's still easier to rely on dotCloud to build server-side.
You can compile from any OS, for any OS. I compile for 32 and 64 bit versions of Windows, OSX, and Linux for my applications. It takes about 5 seconds for all the builds (running serially) to complete.
[edit] Bah, beat by shykes. It's still not hard.
I have to say things are hugely improved since then and at least on par with Heroku and with much more fine grained control over costs. Great work!
I would try out DotCloud if it were an open-source PAAS like OpenShift or CloudFoundry.
Heroku also supports Go: https://gist.github.com/299535bbf56bf3016cba
dotCloud sandboxes applications with kernel containers, so you can run any userland process you want.