Typos
This commit is contained in:
parent
429a045d86
commit
192ddf1e30
|
@ -9,7 +9,7 @@ While is possible to create your own image with custom PHP and Node JS versions,
|
|||
image: tetraweb/php
|
||||
```
|
||||
|
||||
The next step is to install zip/unzip packages and make composer available. We will place these in the `before_scripts` section:
|
||||
The next step is to install zip/unzip packages and make composer available. We will place these in the `before_script` section:
|
||||
|
||||
```yaml
|
||||
before_script:
|
||||
|
@ -41,10 +41,13 @@ All these operations will put all files into a `build` folder, which is ready to
|
|||
|
||||
### How to transfer files to a live server?
|
||||
|
||||
You have multiple options: rsync, scp, sftp and so on. For now, we will use scp. To make this work, you need to add a GitLab Secret Variable (accessible on _gitlab.com/your-project-name/variables_). That variable will be called `STAGING_PRIVATE_KEY` and it's the **private** ssh key of your server.
|
||||
You have multiple options: rsync, scp, sftp and so on. For now, we will use scp.
|
||||
|
||||
To make this work, you need to add a GitLab Secret Variable (accessible on _gitlab.example/your-project-name/variables_). That variable will be called `STAGING_PRIVATE_KEY` and it's the **private** ssh key of your server.
|
||||
|
||||
#### Security tip
|
||||
Create a user that has access **only** to the folder that need to be updated!
|
||||
|
||||
Create a user that has access **only** to the folder that needs to be updated!
|
||||
|
||||
After you create that variable, you need to make sure that key will be added to the docker container on run:
|
||||
|
||||
|
@ -59,12 +62,12 @@ before_script:
|
|||
|
||||
In order, this means that:
|
||||
|
||||
1. We check if the `ssh` is available and we install it if it's not;
|
||||
2. create the `~/.ssh` folder;
|
||||
3. we make sure we're running bash;
|
||||
4. we disable host checking (we don't ask for user accept when we first connect to a server; and since every build will equal a first connect, we kind of need this)
|
||||
1. We check if the `ssh-agent` is available and we install it if it's not;
|
||||
2. We create the `~/.ssh` folder;
|
||||
3. We make sure we're running bash;
|
||||
4. We disable host checking (we don't ask for user accept when we first connect to a server; and since every build will equal a first connect, we kind of need this)
|
||||
|
||||
And this is basically all you need on `before_script` section.
|
||||
And this is basically all you need in the `before_script` section.
|
||||
|
||||
## How to deploy things?
|
||||
|
||||
|
@ -74,7 +77,7 @@ As we stated above, we need to deploy the `build` folder from the docker image t
|
|||
stage_deploy:
|
||||
artifacts:
|
||||
paths:
|
||||
- build/
|
||||
- build/
|
||||
only:
|
||||
- dev
|
||||
script:
|
||||
|
@ -87,16 +90,17 @@ stage_deploy:
|
|||
|
||||
### What's going on here?
|
||||
|
||||
1. `only:dev` means that this build will run only when something is pushed on the `dev` branch. You can remove this block completely and have everything be ran on every push (but probably this is something you don't want)
|
||||
1. `only:dev` means that this build will run only when something is pushed to the `dev` branch. You can remove this block completely and have everything be ran on every push (but probably this is something you don't want)
|
||||
2. `ssh-add ...` we will add that private key you added on the web UI to the docker container
|
||||
3. we will connect via `ssh` and create a new `_tmp` folder
|
||||
4. we will connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder
|
||||
3. We will connect via `ssh` and create a new `_tmp` folder
|
||||
4. We will connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder
|
||||
5. We will connect again to `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
|
||||
6. We connect to ssh and remove the `_old` folder
|
||||
|
||||
What's the deal with the artifacts? We just tell GitLab CI to keep the `build` directory (later on, you can download that as needed).
|
||||
|
||||
#### Why we do it this way?
|
||||
|
||||
If you're using this only for stage server, you could do this in two steps:
|
||||
|
||||
```yaml
|
||||
|
@ -109,6 +113,7 @@ The problem is that there will be a small period of time when you won't have the
|
|||
So we use so many steps because we want to make sure that at any given time we have a functional app in place.
|
||||
|
||||
## Where to go next?
|
||||
|
||||
Since this was a WordPress project, I gave real life code snippets. Some ideas you can pursuit:
|
||||
|
||||
- Having a slightly different script for `master` branch will allow you to deploy to a production server from that branch and to a stage server from any other branches;
|
||||
|
|
Loading…
Reference in New Issue