2017-11-09 11:30

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


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:

├── bin
├── pkg
└── src
    │   ├── 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?

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • dongshou1856 dongshou1856 4年前

    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 script to change GOPATH and build it your way. Then call from your Buildfile.

    2) Change your main package to be a regular package (e.g. 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 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!

    点赞 评论 复制链接分享