M
M
Maxim2016-07-14 16:11:48
PostgreSQL
Maxim, 2016-07-14 16:11:48

How to deploy a Go application?

In general, the task is as follows:

  • Build from binaries (http api + several daemons) deb package
  • Running daemons via systemd (or alternative)
  • Run database migrations when installing or running a new version of a deb package
  • The server should not have any utilities for deployment, migrations, etc., we do not put go there. That is, the deb package is an independent unit;

I did not find the best way on the Internet, can someone tell me about the following questions:
  1. How to organize a repository with sorts of go code, whether it is necessary to add a framework deb package there, maybe binaries. Or do I need to create a new folder each time for a new package?
  2. How to run migrations during installation? Should this be a solution in the main application on go, and deb package to push migrations, for example, to /etc/app/migrations. Or create a separate binary for this, which can work with the configs of our application.
  3. Organization of work with systemd. I had no experience with him. What to look for, have you come across a rake? Maybe there are better alternatives?

Answer the question

In order to leave comments, you need to log in

4 answer(s)
S
sim3x, 2016-07-14
@sggr

On practice

The server should not have any utilities for deployment, migrations, etc., we do not put go there. That is, the deb package is an independent unit;
you will either have to store the version injection sequence outside of the package, or the version that came before the package. And then write the logic how to process different options - there is a version, there is no version, etc.
Running daemons via systemd (or alternative)
since alternatives are gradually being cut out of distributions, then there is no choice in fact.
In theory
a script will be enough to update
the project build git to
copy a file that will do
copy migrations of a couple of files that the package manager needs
in the deb package you should have all the migrations (or all the migrations that may need at least some kind of installation)
In the environment you should have a file or environment variable of the latest working version
Read the variable - run your migration file to raise the version to the current version from the package Keep in mind
that it's good practice to create both upgrade and downgrade migrations
Rollback packages, I would not advise - it's easier to upgrade the version of the package and indicate in it that you want to roll back to the previous version

P
Philipp, 2016-07-15
@zoonman

capistrano

V
vyachin, 2016-07-15
@vyachin

ansible is better)) there is no need to litter the system with ruby ​​installation. Ansible uses python, and it is available in almost any linux system

N
Nikita Pavlov, 2016-07-15
@NikiN

Can you do it in docker and not worry?

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question