如何使用自定义项目文件夹结构在Beanstalk中部署Go Web应用程序

Question

I'm new to Go. I am trying to deploy a simple web project to EB without success. I would like to deploy a project with the following local structure to Amazon EB:

$GOPATH
├── bin
├── pkg
└── src
    ├── github.com
    │   ├── AstralinkIO 
    │   │   └── api-server <-- project/repository root
    │   │       ├── bin
    │   │       ├── cmd <-- main package
    │   │       ├── pkg
    │   │       ├── static
    │   │       └── vendor

But I'm not sure how to do that, when building the command, Amazon is treating api-server as the $GOPATH, and of course import paths are broken.

I read that most of the time it's best to keep all repos under the same workspace, but it makes deployment harder..

I'm using Procfile and Buildfile to customize output path, but I can't find a solution to dependencies.

What is the best way to deploy such project to EB?

Answer 1

Long time has past since I used Beanstalk, so I'm a bit rusty on the details. But basic idea is as follows. AWS Beanstalk support for go is a bit odd by design. It basically extracts your source files into a folder on the server, declares that folder as GOPATH and tries to build your application assuming that your main package is at the root of your GOPATH. Which is not a standard layout for go projects. So your options are:

1) Package your whole GOPATH as "source bundle" for Beanstalk. Then you should be able to write build.sh script to change GOPATH and build it your way. Then call build.sh from your Buildfile.

2) Change your main package to be a regular package (e.g. github.com/AstralinkIO/api-server/cmd). Then create an application.go file at the root of your GOPATH (yes, outside of src, while all actual packages are in src as they should be). Your application.go will become your "package main" and will only contain a main function (which will call your current Main function from github.com/AstralinkIO/api-server/cmd). Should do the trick. Though your mileage might vary.

3) A bit easier option is to use Docker-based Go Platform instead. It still builds your go application on the server with mostly same issues as above, but it's better documented and possibility to test it locally helps a lot with getting configuration and build right. It will also give you some insights into how Beanstalk builds go applications thus helping with options 1 and 2. I used this option myself until I moved to plain EC2 instances. And I still use skills gained as a result of it to build my current app releases using docker.

4) Your best option though (in my humble opinion) is to build your app yourselves and package it as a ready to run binary file. See second bullet point paragraph here

Well, which ever option you choose - good luck!