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?

Improve this question

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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
    Commented Aug 8, 2019 at 5:37
  • Separate pre-deployment tasks from production. You don't want to jeopardize the later. Today, compute power is cheap...
    – vonbrand
    Commented Aug 12, 2019 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.