Laptop with Git and GitLab logos on the screen push pull code symbol

Create git repository and push your code


Make sure that you've taken a look at the following tutorial(s) before you continue:

In this tutorial example.com will be used for project's domain name. kubectl commands presented in this tutorial should be executed from the root of tutorial's git repository.

By now you should have your secured WordPress website up and running. 

You are going to learn

  • how to initialize local git repository
  • how to add and commit files to your local repository
  • how to push those changes to remote repository
  • how to pull changes from remote repository
  • how to use GitLab's deploy keys for repository authentication
  • how to use git's sparse checkout

Keeping track of your code with git

Nowadays it is hard to imagine coding without source code management. It is an absolute must have if you think seriously about your project. Git is a beautiful solution and you can easily find a supplier of a free remote git repository. GitLab offers one and many other things that are useful in a modern software project. It is my favorite solution so I highly recommend using it. This part of the tutorial series can however be finished using any other remote git repository.

1
Git authorization automation(Optional)

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

This option might be considered less secure than entering your git login and password but it's more convenient.

You need to add GitLab deploy key first. Select your project on GitLab and go to SettingsRepository. Find Deploy Keys section and click Expand.

Generate new SSH key pair. You can skip creating the password with Enter

ssh-keygen -t rsa -C "[email protected]" -b 4096

Copy contents of public key and use it to create deploy key on GitLab. Create one with write access allowed. In order to add files to the repository from the Pod level you need to allow write access for the deploy key. Learn more about GitLab authentication over SSH

Add Secret containing the keys

kubectl create secret generic gitlab-deploy-key --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub --from-file=k8s/other/.ssh/config

Edit docker/wordpress/entrypoint.sh. Uncomment section Git authorization automation

Edit k8s/wordpress/deployment.yaml. Uncomment two sections named ssh-keys. Modify tag of your docker image and increment version number.

image: registry.gitlab.com/USERNAME/PROJECT_NAME/wordpress:v1.0.1

Docker image needs to be re-built for changes to take effect. Next thing to do is push the image to container registry. WordPress Deployment needs to be deleted and re-created to pull new docker image.

docker build -t registry.gitlab.com/USERNAME/PROJECT_NAME/wordpress:v1.0.1 docker/wordpress
docker push registry.gitlab.com/USERNAME/PROJECT_NAME/wordpress:v1.0.1
kubectl delete deployment DEPLOYMENT_NAME
kubectl apply -f k8s/wordpress/deployment.yaml

By incrementing the version number of docker image you mark the fact that changes have been made to the image. Keeping the changelog describing those changes is a good practice.

Secret is visible on the Pod as a mounted directory. If path already exists it will be overwritten. Inside that directory there will be three files created: ssh-privatekey, ssh-publickey and config.
Secret resides inside deployer's home directory under .ssh/secret/. This way .ssh/ directory will be writable and ssh client can create known_hosts file there. .ssh/config file will be a symbolic link to .ssh/secret/config.

Step notes

Once you think you have everything you need pushed into the repository removing write access would be a safe and smart thing to do. Alternatively you can create another deploy key without write access and a corresponding Secrets. You could then switch Secrets depending on your needs.

If you have more than one GitLab project, you can allow deploy keys to be used by many projects. This way you only have to create one Secret. You can then use it in many different Deployments. Security-wise this is not the best practice but it sure is convenient.

2
Initialize git repository and configure GitLab connection

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

Connect to your WordPress container

kubectl exec -it POD_NAME -- bash -l

Inside /var/www/example.com run following commands

su deployer
git init
chmod 700 .git

Choose on of two options below

  1. No SSH key used. Username and pass entered manually
    git remote add origin https://gitlab.com/USERNAME/PROJECT_NAME.git
  2. GitLab's deploy key will be used for SSH authentication. No need for username and pass verification
    git remote add origin [email protected]:USERNAME/PROJECT_NAME.git

Enter GitLab username and pass if required.

If you have chosen SSH Deploy key option then .git/config should contain

[remote "origin"]
 url = [email protected]:USERNAME/PROJECT_NAME.git

Finally you can check if GitLab connection using SSH deploy key is working correctly.

3
Ignore some files with .gitignore

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

If you have created some code for WordPress now you can push it to your repository. You certainly do not want to push everything inside your wp-content/ directory.

Create .gitignore file in the same directory as your wp-content/ is and put following content inside

touch .gitignore
chmod 600 .gitignore

Example .gitignore content

*.log
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/wp-cache-config.php
wp-content/plugins/PLUGIN_NAME1
wp-content/plugins/PLUGIN_NAME2
wp-content/themes/THEME_NAME1
wp-content/themes/THEME_NAME2

All of the plugins that have not been created or modified by you should be in .gitignore. The same goes for themes. You do not need to add their code to your repository unless you have a case that requires it. For example you might want to keep some plugin out of .gitignore in order to examine the plugin's code. You can push plugin's code from the Pod and then conveniently pull it using your favorite IDE.

4
Add files to local repository and push them to remote one

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

Before you commit your files, you need to set your email and name for the local repository.

git config user.email "[email protected]"
git config user.name "Your Name"

Git repository has been initialized and you've decided what is going into the repo and what is not. Time to add files to your local repository first

git add .gitignore
git add conf/*
git add wp-content/*

You are ready to commit and push your code

git commit -m "Initial commit of wp-content"
git push -u origin master

Now that you have wp-content/ in your remote git repository check if you can fetch

git fetch origin

Step notes

If your repository contains no files then push should work just fine. If you already have some files in that remote repository then the push will fail because remote contains work that you do not have locally. In that case you can do as follows. Configure sparse checkout first to omit files that you do not want pulled to the Pod. Pull and then push.

5
Configure git for sparse checkout(Optional)

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

Sparse checkout means that only specified paths should be pulled from the repository. In some cases you do not need to checkout other directories residing in the root of your repository. Git's sparse checkout functionality is very helpful with that.

Enable Sparse Checkout mechanism first.

git config core.sparsecheckout true

Add paths that you want to checkout to .git/info/sparse-checkout

echo /.gitignore >> .git/info/sparse-checkout
echo /wp-content/ >> .git/info/sparse-checkout
echo /conf/ >> .git/info/sparse-checkout

Notice that slash / in front of the path. It tells git to get those directories from the root of the repository. If you do not include the slash then git will checkout any files whose parent directory is called wp-content or conf.

6
Pulling changes from remote repository

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

Retrieving changes from remote git repository is easy. Sparse checkout will prevent pulling any unwanted files.

git pull origin master
git pull

Checking out a specific directory can be an option if for some reason you're not using sparse checkout.

git checkout origin/master -- wp-content/

Let's assume that some files in the repository have been modified remotely. In order to check status and then pull changes use commands below

su deployer
cd /var/www/example.com
git fetch origin
git status wp-content/plugins/MODIFIED_PLUGIN_NAME/
git pull origin master

or if you're not using sparse checkout

git checkout origin/master -- path/in/your/repo/to/wp-content/plugins/MODIFIED_PLUGIN_NAME/

Good job. You deserve a bottle of Grog. Arrrr !
Success ! Let's open a case of Rum. Arrrr !
New skills gained. Beers all around! Arrrr !
Thanks for reading ! Please
  •  
  •  
  • 1
  •  
  •  
  •  
  •  
  •  

Leave a comment

Your email address will not be published. Required fields are marked *