月: 2018年8月

はじめに

Ansibleで構成管理をしていると、ある全台ではなくある特定のサーバだけ設定を変えたい時がある。WEBサーバ全体ではなく、その中の1台のみ実施したいという時だ。Ansibleのtipsを紹介。

Ansibleで特定サーバのみ振る舞いを変える

例えばcronをコメントアウトすることを例にする。

1. Ansibleのinventoriesのhostsファイルを変更
   以下の通り

   [web]
   web01 ansible_host=192.168.10.10 ansible_ssh_private_key_file=~/.ssh/key
   web02 ansible_host=192.168.10.11 ansible_ssh_private_key_file=~/.ssh/key
   
   

2. ansible-playlistを編集し、サーバ名を取得する。

   - name: check Hostname
   hostname:
   name: '{{ inventory_hostname }}'
   tags: edit_cron

   inventoriesでいうところのweb01やweb02がこれに該当する
   

3. replaceを使う
   特定サーバの場合振る舞いを変える
   web02だけあるcronを変えたい場合

   - name: comment out for 02
   replace:
   path: /var/spool/cron/cronuser
   regexp: '^\* \* \* \* \* echo hello'
   replace: '#* * * * * echo hello'
   when: inventory_hostname is search("02")
   tags: edit_cron

   を定義することにより、02のecho helloだけコメントアウトされる

 

はじめに

mysqlのユーザーを作成し、権限を適宜設定することが多いがよく使うコマンドをまとめた。

ユーザーを確認する

MariaDB [(none)]> select user,host from mysql.user;
+--------+------------+
| user   | host       |
+--------+------------+
| root   | 127.0.0.1  |
| redash | 172.18.0.% |
| root   | ::1        |
|        | instance-1 |
| root   | instance-1 |
|        | localhost  |
| root   | localhost  |
+--------+------------+
7 rows in set (0.00 sec)

MariaDB [(none)]> show grants for 'redash'@'172.18.0.%';

ユーザーを作成する

パスワードを平文で入れる

GRANT USAGE ON *.* TO 'usera'@'192.168.10.10' IDENTIFIED BY 'password123';

パスワードをハッシュ化して登録

SELECT PASSWORD('password123');
#出力されたハッシュを以下に入れる
GRANT USAGE ON *.* TO 'usera'@'192.168.10.10' IDENTIFIED BY PASSWORD '*6D4B1BD281FE14CCBC97B934';

権限付与

参照のみ

GRANT SELECT, EXECUTE ON `databasea`.* TO 'usera'@'192.168.10.10'

データ操作言語(DML)文

GRANT SELECT, INSERT, UPDATE, DELETE, EXECUTE ON `databasea`.* TO 'usera'@'192.168.10.10'

権限を剥奪する

全権限を剥奪する

REVOKE ALL ON `database`.* FROM 'usera'@'%' 

部分的に剥奪する

REVOKE DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON `database`.* FROM 'usera'@'%' 

接続元を変更する

どこからでもアクセスできた状態からアクセス元を特定セグメントからのみに絞る

rename user 'usea'@'%' to 'usera'@'192.1.%';

 

パスワード変更

すでに作ったユーザのパスワード変更は以下のコマンド

set password for 'usera'@'192.168.10.10'=password('パスワード');

ユーザを削除する

DROP USER 'usera'@'192.168.10.10';

 

はじめに

Gitと連携させCIを動かす事が増えて来た。GitHubと連携させTravis CIもいいし、Circle CIもいいだろう。GitLab CIのいいところは、自前で環境さえ準備できさえすれば非常に低コスト（IaaSの運用コストのみ）で動かす事ができるのが魅力だ

設定方法

前提条件

GitLabが動作できていること

本手順は、GitLab 10.3.7を前提としている

GitLabの設定

GitLabの左メニューで Settings -> CI/CDを選択する

General piplines settingsで
「Instance default」を選択し、Runner Tokenをひかえる

 

CIサーバ側の設定

GitLab CIサーバでGitLab runnerの設定をいれる

# sudo gitlab-runner register

Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://git.sumito.jp/
Please enter the gitlab-ci token for this runner:
SJxxxxxxxxxxxx
Please enter the gitlab-ci description for this runner:
[server]: projectA
Please enter the gitlab-ci tags for this runner (comma separated):

Whether to lock the Runner to current project [true/false]:
[true]: true
Registering runner... succeeded runner=xxxxxxx
Please enter the executor: parallels, ssh, virtualbox, docker+machine, docker-ssh+machine, docker, docker-ssh, shell, kubernetes:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

 

automatically reloaded!と表示されれば設定は問題ない

.gitlab-ci.ymlの設定

.gitlab-ci.yml 
variables:
AMI_ID_KUSANAGI: "ami-123456"
INSTANCE_NAME: "${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}_${CI_PIPELINE_ID}"
TMP_ANSIBLE_DIR: "/tmp/gitlab/${CI_COMMIT_SHA}/${CI_PIPELINE_ID}"
DEPLOY_SITE: "wordpress"
SSH_KEY_NAME: "ssh-key"
INSTANCE_LOG: "/tmp/gitlab/${CI_COMMIT_SHA}/${CI_PIPELINE_ID}/run-instances.json"
ALLOCATE_ADDRESS_LOG: "/tmp/gitlab/${CI_COMMIT_SHA}/${CI_PIPELINE_ID}/allocate-address.json"

stages:
- initial
- build
- test
- deploy
- cleanup

########################################################
# STAGE:ANCHORS #
########################################################

# These are hidden jobs that contain the anchors
.server_group_1:
only: &kusanagi_servers
/^(wordpress).*$/

########################################################
# STAGE:INITIAL #
########################################################
make_tmp_directory:
stage: initial
script:
- mkdir -p ${TMP_ANSIBLE_DIR}

# デプロイテスト用インスタンスを作成@kusanagi& t2.medium
run_aws_server_kusanagi:
stage: build
only:
- *kusanagi_servers
script:
# インスタンスを作成
- aws ec2 run-instances --key-name ${SSH_KEY_NAME} --image-id ${AMI_ID_KUSANAGI} --count 1 --instance-type t2.medium --security-group-ids sg-12345678 --subnet-id subnet-12345678> ${INSTANCE_LOG}
# インスタンスにタグ付け
- instance_id=`jq -r .Instances[].InstanceId ${INSTANCE_LOG}`
- aws ec2 create-tags --resources $instance_id --tags Key=Name,Value=${INSTANCE_NAME}
# ElasticIPを払い出してタグ付け
- aws ec2 allocate-address --domain vpc > ${ALLOCATE_ADDRESS_LOG}
- allocation_id=`jq -r .AllocationId ${ALLOCATE_ADDRESS_LOG}`
- aws ec2 create-tags --resources $allocation_id --tags Key=Name,Value=${INSTANCE_NAME}
# インスタンスのステータスがrunningになるまで待つ
- i=1; while [ $i -le 120 ]; do sleep 3; if [ "\"running\"" = `aws ec2 describe-instances --instance ${instance_id} | jq '.Reservations[].Instances[].State.Name'` ]; then break; fi; i=$(expr $i + 1); done
# ElasticIPをインスタンスに紐付け
- aws ec2 associate-address --allocation-id ${allocation_id} --instance ${instance_id}

# Ansible Playbookをgit clone
setup_git:
stage: build
script:
- cd ${TMP_ANSIBLE_DIR}
- git clone git@git.sumito.jp:sumito/projectA.git
- cd projectA
- git checkout ${CI_COMMIT_REF_NAME}

########################################################
# STAGE:TEST #
########################################################
# 全てのAnsible Playbookの構文チェック
check_syntax_ansible:
stage: test
before_script:
- sed -e s%__ROLES_PATH__%${TMP_ANSIBLE_DIR}/projectA/Ansible/roles%g /home/gitlab-runner/.ansible_template.cfg > /home/gitlab-runner/.ansible.cfg
- cd ${TMP_ANSIBLE_DIR}/projectA/Ansible
script:
- ansible-playbook -i inventories/staging/hosts sites/staging/wordpress.yml --syntax-check

########################################################
# STAGE:DEPLOY #
########################################################
# Ansible Deployを実行
execute_ansible:
stage: deploy
only:
- *kusanagi_servers
before_script:
- elastic_ip=`jq -r .PublicIp ${ALLOCATE_ADDRESS_LOG}`
- cd ${TMP_ANSIBLE_DIR}/projectA/Ansible
- sed -si -e s/__IP__/${elastic_ip}/g -e s%__KEY__%/home/gitlab-runner/.ssh/${SSH_KEY_NAME}%g inventories/staging/hosts
- sleep 20
script:
- ansible-playbook -i inventories/staging/hosts sites/staging/${DEPLOY_SITE}.yml -u sumito --limit ${DEPLOY_SITE} --vault-password-file=/home/gitlab-runner/.vault_password

########################################################
# STAGE:CLEANUP #
########################################################
# Deployテストしたサーバリソースを削除@on_success
remove_aws_server_success:
stage: cleanup
only:
- *kusanagi_servers
before_script:
- instance_id=`jq -r .Instances[].InstanceId ${INSTANCE_LOG}`
script:
- sh /home/gitlab-runner/bin/aws/terminate-instance.sh $instance_id
after_script:
- rm -rf ${TMP_ANSIBLE_DIR}

# Deployテストしたサーバリソースを削除@on_failure
remove_aws_server_manual:
stage: cleanup
only:
- *kusanagi_servers
before_script:
- instance_id=`jq -r .Instances[].InstanceId ${INSTANCE_LOG}`
script:
- sh /home/gitlab-runner/bin/aws/terminate-instance.sh $instance_id
after_script:
- rm -rf ${TMP_ANSIBLE_DIR}
when: manual

どのように動くか

今回実施したPipelineは

“`
stages:
– initial
– build
– test
– deploy
– cleanup
“`

の順番で処理が行われるよう骨格を作った。

AWSのインスタンスをたちあげ、環境をセットアップし、ansibleを流す。最後にはテストで使ったイメージを削除するPipeline
gitにpushする度にCIが動くようになり、品質が担保できるようになった。

はじめに

秘密鍵は手元にあるけど、公開鍵がすぐに出せないということがよくある。
しかし、秘密鍵を元に公開鍵を作成することは可能だ

手順

ssh-keygen -yf 秘密鍵

リダイレクトすることにより、ファイルに出力が可能

例

ssh-keygen -yf  /tmp/id_rsa > /tmp/id_rsa.pub.dump

 

確認

オリジナルの公開鍵と、秘密鍵を元に復元した公開鍵の違いはこちら

[root@tsukada ~]# ssh-keygen -t rsa 
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /tmp/id_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /tmp/id_rsa.
Your public key has been saved in /tmp/id_rsa.pub.
The key fingerprint is:
SHA256:HlWiUEHdOU5YteJv38bSB5oXXUQPuxqaubyvJK8dpzs root@tsukada
The key's randomart image is:
+---[RSA 2048]----+
|      .o+o.+ooo..|
|       . .oo=  +o|
|        . .o..o..|
|         . ... ..|
|        S   o ...|
|       . . + +o .|
|        o * ooo= |
|         *E=o.o.*|
|        ..X*.. o+|
+----[SHA256]-----+
[root@tsukada ~]# 
[root@tsukada ~]# ls -l /tmp/id_rsa*
-rw------- 1 root root 1675  8月 17 19:36 /tmp/id_rsa
-rw-r--r-- 1 root root  393  8月 17 19:36 /tmp/id_rsa.pub
[root@tsukada ~]# 
[root@tsukada ~]# ssh-keygen -yf   /tmp/id_rsa > /tmp/id_rsa.pub.dump
[root@tsukada ~]# ls -l /tmp/id_rsa*
-rw------- 1 root root 1675  8月 17 19:36 /tmp/id_rsa
-rw-r--r-- 1 root root  393  8月 17 19:36 /tmp/id_rsa.pub
-rw-r--r-- 1 root root  381  8月 17 19:36 /tmp/id_rsa.pub.dump
[root@tsukada ~]# diff /tmp/id_rsa.pub /tmp/id_rsa.pub.dump
1c1
< ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDhAoTIS70SmsUKkYp+J11UdnbEqmHmJ1rZP9lbXlP7jDqYZbOKV761CIEtgAuObxNDsr7fh2K0/eH4P+Ie1JB4yFsAQdyQnIqR0BEOT+3DKdSVDJP6ec0iOGl5XrAqbx3rs5pCfUBC3tD8EQHpKOrRHxp7m+o3QnljGtAL0cBMb+3n4dw4Lapq3L0ZOaeXzmuH7efOLT/u6wUQVzWACSZ2z4Jssei22nkJXgXXM6pkV7ejkbNZUppKJZe5drYvW4TJPqKYeAktDr6tnhDJ6n1Qgy3SjWGaDcJ7UKa2CG/84y+I9Et2BXiJaUd5qNMBITx26RDMcNoxTbGSOp1IZwPr root@tsukada
---
> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDhAoTIS70SmsUKkYp+J11UdnbEqmHmJ1rZP9lbXlP7jDqYZbOKV761CIEtgAuObxNDsr7fh2K0/eH4P+Ie1JB4yFsAQdyQnIqR0BEOT+3DKdSVDJP6ec0iOGl5XrAqbx3rs5pCfUBC3tD8EQHpKOrRHxp7m+o3QnljGtAL0cBMb+3n4dw4Lapq3L0ZOaeXzmuH7efOLT/u6wUQVzWACSZ2z4Jssei22nkJXgXXM6pkV7ejkbNZUppKJZe5drYvW4TJPqKYeAktDr6tnhDJ6n1Qgy3SjWGaDcJ7UKa2CG/84y+I9Et2BXiJaUd5qNMBITx26RDMcNoxTbGSOp1IZwPr
[root@tsukada ~]# 
[root@tsukada ~]# 

公開鍵の後ろに作成したuser@serverが入るのがオリジナル。入らないのが復元した公開鍵。もちろん機能的にはまったく同じく使うことが可能だ