<p>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.</p>

<p>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 <code>docker-compose</code> 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.</p>

CC BY-SA 4.0
2019-08-08T05:37:32.643Z
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
CC BY-SA 4.0
2019-08-12T14:38:35.507Z
Separate pre-deployment tasks from production. You don't want to jeopardize the later. Today, compute power is cheap...
vonbrand
CC BY-SA 4.0
2019-08-07T20:20:39.770Z
2019-08-07T20:20:39.770Z
Kaymaz
<p>I have a relatively simple understanding of GitLab CI:</p>

<ul>
<li>There is a GitLab server (server A)</li>
<li>There is a separate server with GitLab runners (server B)</li>
<li>And there is some other server - the 'prod' server (server C)</li>
</ul>

<p>From prior experience, I understand that the GitLab runners would do the following:</p>

<ul>
<li>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 <code>.gitlab.ci-yml</code>, which is included in the source control</li>
<li>As defined by the <code>.yml</code> 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.</li>
</ul>

<p>I am opting for a simpler automated deployment setup.. I want 2 servers:</p>

<ul>
<li>Server A (GitLab CE)</li>
<li>Server B: Ubuntu 18 server that has a GitLab runner, AND that serves as a production server</li>
</ul>

<p>Is this a good idea?</p>

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

<p>Is there any reason that I wouldn't want to do this?</p>

<gitlab-ci-runner>
Can a server used for GitLab runners be used as a deployment server?
Zach Smith
# Can a server used for GitLab runners be used as a deployment server?

(Asked by: username_0 on 2019-08-07)

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?

**Tags:** gitlab-ci-runner


---

## 1 answers

### Answer by username_1 on 2019-08-07. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_0**: 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  
> **username_2**: Separate pre-deployment tasks from production. You don't want to jeopardize the later. Today, compute power is cheap...  

---

