After installing a local Jira server recently, I had a search issue and part of the instructions was to stop the running server.
From here:
To stop:
sudo /etc/init.d/jira stop
To start:
sudo /etc/init.d/jira start
Articles, notes and random thoughts on Software Development and Technology
As part of migrating this blog to Docker containers to move to a different VPS provider (here, here and here), I found myself repeating a number of steps manually, which always a good indication that there’s an opportunity to automate some or all of those steps.
Each time I made a change in the configuration or changed the content to be deployed, I found myself rebuilding the Docker image and either running locally, pushing to my test server, and eventually pushing to my prod VPS and running there.
I’m using a locally running GitLab for my version control, so to use its build pipeline features was a natural next step. I talked about setting up a GitLab runner previously here – this is what performs the work for your pipeline.
You configure your pipeline with a .gitlab-ci.yml file in the root of your repo. I defined 2 stages, build and deploy:
stages: - build - deploy
For my build stage, I have a single task which is to build my images using my docker-compose.yml:
build: stage: build script: - docker-compose build tags: - docker-test
For my deploy steps, I defined one for deploying to my test server, and one for deploying to my production VPS. This is the deploy to my locally running Docker server. It changes DOCKER_HOST to point to my test server, and then uses the docker-compose.yml again to bring down the running containers, and bring up the new containers with the updated images:
deploy-containers: stage: deploy script: - export DOCKER_HOST=tcp://192.x.x.x:2375 - docker-compose down - docker-compose up -d tags: - docker-test
And one for my deploy to production. Note that this step is defined with ‘when: manual’ which tells GitLab the task is only run manually (when you click on the ‘>’ run icon):
prod-deploy-containers: stage: deploy script: - pwd && ls -l - ./docker-compose-vps-down.sh - ./docker-compose-vps-up.sh when: manual tags: - docker-prod
Here’s what the complete pipeline looks like in GitLab:
With this in place, now any changes committed to the repo result in a new image created and pushed to my test server automatically, and when I’ve completed testing the changes I can optionally deploy the changes to my prod VPS hosted server.
I’ve wondered a couple of times how you can navigate to a hidden folder and/or select a hidden file when an app requires you to pick a file using MacOS’s file chooser, because by default neither are visible in the chooser.
A quick search found this post and the easy but not so obvious answer is to use either:
To connect to an EC2 instance over SSH, if the permissions on your .pem file are too broad then you’ll see this error:
Permissions 0644 for ‘keypair.pem’ are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
chmod the .pem file to 0400 and then you should be good. This is described here.