Implementing version control to server

Discussion in 'Systems Administration' started by Miniroid, May 29, 2019.

  1. Hello, I was wondering if it is possible to do the following in order:

    1. Commit Minecraft server files to a repository
    2. Deploy the committed files to a test server once committed to 'test' branch
    3. Once tested and I am happy with changes, with a push of a button, it will then restart the main server with the changes made while ensuring that player data are untouched (to be placed in .gitignore).

    It will be great if this is possible and if you can explain in a brief summary of how I can go around doing so.
     
  2. MiniDigger

    Supporter

    on your local machine or smth:
    > git init
    > echo "stuff" > .gitignore
    > git checkout -b test
    > git add .
    > git commit -m "initial"
    > git remote add origin https://gitlab.yourdomain.com/Group/Repo
    > git push origin test

    on your test server
    > git clone -b test https://gitlab.yourdomain.com/Group/Repo
    or after the initial clone to update stuff
    > git pull

    once you arge happy, merge test into master
    > git checkout master
    > git merge test
    > git push origin master

    on your prod server you can then clone it
    > git clone https://gitlab.yourdomain.com/Group/Repo
    or after the initial clone to update stuff
    > git pull
    you should do that while the server is shutdown, so depending on how you run your server, you need to do smth like
    > service minecraft stop
    > yourUpdateScript.sh
    > service minecraft start

    I wouldn't do this with world files tho. you also do regular house keeping if you change plugin files often, else your repo will become big pretty fast.
     
  3. Thank you for the comprehensive answer! Would there be a way for it to automatically detect commit changes in the branches, and do these commands automatically?
     
  4. MiniDigger

    Supporter

    like you want to automatically update your test server if you commit something to the test branch?
    thats possible, yes
    how do you run your servers? you don't use something modern like kubernetes or docker swarm or anything? because then it would be extremly easy :D
     
  5. I am thinking of moving it to docker, but I am new to the concept of containerization
     
  6. Docker is a good thing to learn, highly recommend it. They have tutorials and docs on their site, kubernetes also has a very good tutorial if you decide to use that.
     
  7. I sort of understand the basic idea of docker, but what should I look out for if I would like to specifically look for a way to automatically build the docker image whenever I do a commit?
     
  8. Use continuous integration. When you commit something, you can push things. You push things to a certain central repository system, like GitLab, GitHub, Bitbucket, etc. You can configure pipelines on these repositories. GitLab has runners built in, GitHub has a few options there as well, and Bitbucket also has their own setup to offer. You could also use something like Jenkins. Assuming you would use something like Jenkins, you can create a pipeline to trigger a certain action. These are just commands. From your pipeline, in Jenkins for example, you can run a few Docker commands. One command could be to build a new version of the image, another command could be to publish this image somewhere, and a final command could be some kind of deployment command towards Kubernetes that Kubernetes should reload its images and redeploy things.

    Here's a 5 minute introduction which high-level explains what Kubernetes is:

    He actually makes a mistake in his drawing somewhere. Let's see if anyone notices it ;)

    It looks like you're trying to run your entire server in Docker, which is great! Do be sure to fully understand what it is. Mostly, be sure to understand the behavior of persistent volumes. If you're getting into Docker and want to run everything on it, highly recommend to look into Kubernetes, which is a desired-state infrastructure configuration... thing. You basically create configuration files stating what you want to run, in what quantity, how much CPU/RAM things should get, and so on. You then buy a few machines, add them to the Kubernetes cluster, and then Kubernetes will figure out how to get it done. It's not the easiest thing, but once you get into it, you won't regret it.
     
    #8 MrDienns, May 30, 2019
    Last edited: May 30, 2019
    • Like Like x 1