Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-08-08T05:37:32.643Z
Answers: 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
Answers: Zach Smith
Answers: CC BY-SA 4.0
Answers: 2019-08-12T14:38:35.507Z
Answers: Separate pre-deployment tasks from production. You don't want to jeopardize the later. Today, compute power is cheap...
Answers: vonbrand
Answers: CC BY-SA 4.0
Answers: 2019-08-07T20:20:39.770Z
Answers: 2019-08-07T20:20:39.770Z
Answers: Kaymaz
Body: <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>
  
Tags: <gitlab-ci-runner>
Title: Can a server used for GitLab runners be used as a deployment server?
UserDisplayName: Zach Smith
ThreadText: # 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...  
  
  ---
  
  