0

I have a Go package running on Windows and is working fine but now I'm at a stage where I would like to test this on production CentOS 6.5 server.

What is the best practice to deploy this from Windows to CentOS?

Would I have to use my Git repo to distribute to Linux operating system, compile then deploy the binary to the server?

Also I have multiple files, so I would imagine go build *.go would suffice or are there better options for doing compilation?

Passionate Engineer
  • 10,034
  • 26
  • 96
  • 168
  • Directory structure: use a GOPATH and make this a package; see [this](http://stackoverflow.com/questions/20628918/cannot-download-gopath-not-set/20629533#20629533) on workspace structure (it's Unix-centric, but you can adapt the ideas to Windows). You shouldn't have to name files in your `go build` command, once your app gets past the oneoff-script stage. – twotwotwo Sep 21 '14 at 09:02
  • 1
    You *can* build a Linux app from your Windows machine (Google "golang cross compiling"), and then you hopefully just copy the binary over and it works, but it might also pay off for you to get a full Go environment set up in Unix-land (i.e., start by going to golang.org and downloading the binaries onto a CentOS machine). – twotwotwo Sep 21 '14 at 09:05
  • Specifically, it could be worth getting Go set up on the Unix target machine because source is quicker to move around than binaries, because if you ever use `cgo` that will make cross-compiling harder (but not impossible), and because if you're running this on Linux it's probably worth picking up some familiarity with Unix stuff generally. – twotwotwo Sep 21 '14 at 09:17
  • I used [Gox](https://github.com/mitchellh/gox) when starting with cross-compilation from Windows -> *nix. Really really simple to start with. – Simon Whitehead Sep 21 '14 at 10:19
  • @twotwotwo I wouldn't suggest building on the target machine. That's losing one of Go's best traits, the portable executables. Having a Linux build machine is worth exploring if you don't trust cross compilation. But building on the target machine just makes operating your machines and scaling harder. I work for a company that has hundreds of servers and dev machines, and not building on the target makes life much simpler. – Not_a_Golfer Sep 21 '14 at 10:21
  • @Not_a_Golfer I think you are right. I work for the company who has many dev machines and servers. I want to make sure that compilation is done correctly on Windows server for Linux then easily deployable. This way I am easily able to convince my managers on using Go for new projects in my company – Passionate Engineer Sep 21 '14 at 10:25
  • @SimonWhitehead I used `go get github.com/mitchellh/gox` then `gox -h` but it outputs `gox: command not found` error. – Passionate Engineer Sep 21 '14 at 10:31
  • @PassionateDeveloper is $GOPATH/bin in your system path? – Not_a_Golfer Sep 21 '14 at 10:59
  • You have to make sure that wherever it is compiled to is in your `PATH` variable for your system. – Simon Whitehead Sep 21 '14 at 11:40
  • @Not_a_Golfer `$GOPATH\bin` contains gox.exe – Passionate Engineer Sep 21 '14 at 11:47
  • @PassionateDeveloper But does `$PATH` contain `$GOPATH/bin`? If not.. you can't run gox from _anywhere_. You must be in `$GOPATH/bin` to run gox.. but if you put it in `$PATH` you can run it anywhere. – Simon Whitehead Sep 21 '14 at 11:48
  • 1
    It works now. I did `export PATH=$PATH:{gox.exe path}` and it worked! Thanks a lot – Passionate Engineer Sep 21 '14 at 11:52
  • @twotwotwo you should make an answer from your comments – Not_a_Golfer Sep 21 '14 at 12:13

1 Answers1

1

What is the best practice to deploy this from Windows to CentOS?

As far as best practices go I would recommend using continuous integration. You can setup jenkins, or there are some cloud options out there: codeship.io, travis-ci.org, drone.io, wercker.com, ... Some of them have free plans available.

Basically you'd commit your code to git and push that out to Github (or Bitbucket if you want free private repos). The continuous integration server will be notified whenever you push out changes, and will build, test and create a release tar archive of your project. You can then take this resulting tar and download it to your CentOS box. In 6.5 you'll need to create an init.d script to keep your program up and running. You can see an example here (the system v script).

CentoOS 7 uses systemd now which would be slightly easier to setup.

Taking this one step further it's also possible to setup continuos deployment, in which the download, extraction and installation can also be automated. Depending on your project it may or may not make sense to set up continuous deployment. (Auto-pushing to production might be a little too automatic) You can find an example in wercker here.

Although there is an an up-front cost to setting up continuous integration if this is a project that other people will contribute too, or one that you intend to work on long-term, the cost will definitely be worth it. (Future you will be greatful when you come back to this project 6 months from now, change 1 line of code, and don't have to remember all the manual steps it took to deploy)

Caleb
  • 9,272
  • 38
  • 30