0

I have a relatively simple understanding of GitLab CI:

  • There is a GitLab server (server A)
  • There is a separate server with GitLab runners (server B)
  • And there is some other server - the 'prod' server (server C)

From prior experience, I understand that the GitLab runners would do the following:

  • On a push to source control, GitLab (server A) would contact the GitLab runner (server B), and the runner would pull the source control and execute jobs as defined in .gitlab.ci-yml, which is included in the source control
  • As defined by the .yml file, a Docker image would be added back to server A (to the GitLab Docker registry). Then the runner would login to server B, pull the docker image, and start it.

I am opting for a simpler automated deployment setup.. I want 2 servers:

  • Server A (GitLab CE)
  • Server B: Ubuntu 18 server that has a GitLab runner, AND that serves as a production server

Is this a good idea?

It seems like I can configure the runner to just run a docker-compose up --rebuild command, and that this would essentially work.

Is there any reason that I wouldn't want to do this?

Zach Smith
  • 103
  • 4

1 Answers1

2

GitLab and GitLab CI are not two servers: they are softwares installed on a server. Now, while both can be installed on the same server, they can be split for scaling reason.

Now your question: it all depends on what type of services your are running. Bear in mind that CI can take CPU/memory and disk bandwidth while running your CI (docker image build, composer, npm, Java, etc.). Doing so can slow down your production server. Another reason not to run docker-compose directly is to avoid downtime: what if there is a mistake during the build or the deployment? Your production will be down. You may want to look at blue/green deployment.

Kaymaz
  • 355
  • 1
  • 8
  • Thanks. This is case of learning to walk before running. For now, it's okay if the production goes down for a few minutes while deploying. The key thing here is automated deployment via a means that is scalable – Zach Smith Aug 08 '19 at 05:37
  • Separate pre-deployment tasks from production. You don't want to jeopardize the later. Today, compute power is cheap... – vonbrand Aug 12 '19 at 14:38