Make sure that you've taken a look at the following tutorial(s) before you continue:
- - First steps
- $300 free trial. How to use it wisely ?
- Let's get MySQL up and running on Kubernetes
- Let's get WordPress up and running on Kubernetes
- SSL secured WordPress website on Kubernetes
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
- 1Git authorization automation
- 2Initialize git repository and configure GitLab connection
- 3Ignore some files with .gitignore
- 4Add files to local repository and push them to remote one
- 5Configure git for sparse checkout
- 6Pulling changes from remote repository
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. 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.
This option might be considered less secure than entering your git login and password but it's more convenient.
You need to add 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
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
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.
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:
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
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.
Connect to your WordPress container
/var/www/example.com run following commands
Choose on of two options below
- No SSH key used. Username and pass entered manually
- GitLab's deploy key will be used for SSH authentication. No need for username and pass verification
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.
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
.gitignore file in the same directory as your
wp-content/ is and put following content inside
*.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.
Before you commit your files, you need to set your email and name for the local repository.
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
You are ready to commit and push your code
Now that you have
wp-content/ in your remote git repository check if you can fetch
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.
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.
Add paths that you want to checkout to
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
Retrieving changes from remote git repository is easy. Sparse checkout will prevent pulling any unwanted files.
Checking out a specific directory can be an option if for some reason you're not using sparse checkout.
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
or if you're not using sparse checkout