Recently, the development of kubernetes, as well as a large number of applications in our company, I can’t wait to have a taste. Although my blog is a pure static site based on hexo, it doesn’t stop me from migrating it to kubernetes! After all, compared with GitHub, pages is more flexible, more controllable, emmmm… Well, I can’t make it any more. In a word, life is a toss? Let’s start.
The code involved in this article (that is, my blog) is completely open sourcehttps://github.com/wi1dcard/blog。
Building docker image
To get on kubernetes, the first thing to do is to package the image for the project. Dockerfile is very simple:
#Adoption nginx:stable-alpine As the base image FROM nginx:stable-alpine #Copy. / public to image / usr / share / nginx / HTML COPY ./public /usr/share/nginx/html #Prompt to expose TCP protocol port 80 EXPOSE 80/tcp
I choose docker hub as docker registry. If you have private projects, permission control and other related requirements,Quay.ioMaybe it’s a better choice.
Of course, it’s up to Ci to build. It is not recommended to change build manually every time, which is time-consuming and error prone.
Now I’m using Travis CI for my blog. I have also considered:
- Circle CI. After the trial, I feel that the configuration file (in my personal style) is a bit counter intuitive and give up.
- Gitlab Ci, I think the best CI / CD at present. All my private projects with CI / CD requirements are in gitlab. But considering (1) open source blog code, (2) payment for gitlab CI for GitHub repos, (3) two VCs feel strange, so give up.
- GitHub actions is one of the seed players who beat CI / CD in beta. Unfortunately, the documents are not complete enough and the stability is poor, so we have to give them up for the time being.
- Docker hub is not bad if it is only used to build public images, but (1) CI is strongly bound to docker registry, so I want to change the registry (such as the one mentioned above) Quay.io ）It will be very cumbersome, (2) the construction speed is extremely slow… Slow… It’s probably because there are too many users, which is excusable, (3) after the image packaging is completed, you need to use helm to deploy (that is CD) to cluster, obviously not suitable for this scenario.
env: global: - DOCKER_ User name = wi1dcard # my docker hub user name - DOCKER_ IMAGE=$DOCKER_ User name / blog # docker image name - DOCKER_ TAG=build-$TRAVIS_ BUILD_ Number # docker image tag
These variables will be used later.
$DOCKER_TAGIts value is dynamic, that is, it changes with each build, which is determined by Travis Ci’sPredefined environment variablesIt’s made by splicing.
before_scriptThe script of the build process is defined in
before_script: - build/build.sh
Due to the complexity of the build and release process, and for the future (possible) migration to gitlab Ci, I did not list all the scripts in the
.travis.ymlInside, likealipay-sdk-phpAnd so on.
I put all the CI related content in the
build/build.shThe main tasks of the project are as follows:
- Install dependencies, such as hexo.
- implementlintProcess, check markdown syntax, etc.
- Render static site, generate PDF resume.
- Build docker image.
Publish docker image
I put the CD related content in the
deploy/catalog. just as
.travis.ymlAs defined, the deployment script is located atdeploy/deploy.sh：
script: - deploy/deploy.sh
First, log in to docker hub, and then push the image
echo "Logging in Docker Hub..." echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin echo "Pushing images to Docker Hub..." docker push "$DOCKER_IMAGE"
Note that the previously defined environment variables are used here. Among them,
$DOCKER_PASSWORDI define it in the private environment variable of Travis CI:
There are also two environment variables
KUBECONFIG_BASE64I’ll use it later.
You can do it inhereView the pushed images and tags.
$DOCKER_TAGIs the value of is dynamic, so every CI build image will have a unique tag corresponding to its build ID.
The benefits are obvious to me:
- Immutable。 The image created each time is just like git commit, leaving an unchangeable mark.
- Clear and unambiguous. You don’t know the current situation quickly
lastetIt is the product of which construction.
- Easy to roll back. Although you can rebuild the image, if you keep the image of each build, you can quickly and perfectly roll back to any version (especially to prevent the same git commit from producing different images multiple times).
In fact, after a year of operation and maintenance, I found that sometimes confusion is more terrible than “I don’t know”. Some implicit statements can lead to a meaningless waste of a whole day on a tiny issue. Therefore, if there is a conflict between simplicity and elegance and clarity, I will not hesitate to chooseIt’s clearExplicitly declare that although it may look a bit ugly now, it may be a big help in debugging in the future.
(to be continued)
This work adoptsCC agreementReprint must indicate the author and the link of this article