susukinosu

つらみ八幡宮、本殿です

Jenkinsで環境毎に処理を分ける(Declarative Pipeline)

Jenkinsの真髄はJenkinsfileにあると思う昨今

ジャバとめちゃ久しぶりに戯れた時、Jenkinsおじでちょっと試したので記録。

(とにかくジャバと戯れたい方はここじゃなくてこっち↓)

arigato-java.download

複数のAWSアカウントがあった場合

pom.xmlに、DEVやらSTGやらの profile を用意しておく。

デプロイ先環境毎によしなにビルドとデプロイさせる

Jenkinsの環境変数に、デプロイ先環境(DEPLOY_TARGET とか)を持たせておく。

pipeline {
  agent any
  stages{
    stage('Build application') {
      steps {
        sh "mvn clean package -P ${DEPLOY_TARGET}"
      }
    }
    stage('Deploy to DEV') {
      when {
        environment name: 'DEPLOY_TARGET', value: 'DEV'
      }
      steps {
        どこかへデプロイする処理(CodeDeployとか)
      }
    }
    stage('Deploy to STG') {
      when {
        environment name: 'DEPLOY_TARGET', value: 'STG'
      }
      steps {
        どこかへデプロイする処理(CodeDeployとか)
      }
    }
  }
}

実際にガッツリ使う際はpost Sectionやenvironment, options Directiveとかも合わせて使うと良い。

Jenkinsfileで書かずフリースタイルジョブを延々と作り続けると、

ある種の職人芸が生まれてしまったりメンテナンスがめんどい場合もあるので、

(読み書きができれば)管理しやすそうなJenkinsfileのほうが、チームでやるなら良さげ。

前までのScripted Pipelineに比べると、

Declarative Pipelineはめちゃ書きやすい気がする(公式も推奨)ので、使うならそちら。

参考

jenkins.io

ubuntu MATE 18.10 on GPD Pocketでbluetoothをデフォルトで無効にする

ubuntu MATE起動時に、bluetoothも勝手に有効になっていたため設定を変えた。

$ systemctl is-enabled bluetooth
enabled

$ sudo systemctl disable bluetooth
Synchronizing state of bluetooth.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable bluetooth
Removed /etc/systemd/system/dbus-org.bluez.service

$ systemctl is-enabled bluetooth
disabled

service nameがbluetoothってまんまだな……

$ systemctl list-unit-files --type=service

実行したらそのまんま書いてあって、謎にほほーっとなってしまった。

どうでもいいけど、macOS触ってる身にはubuntu MATEでPlank使うと何かと捗る(気がする)。

あとChromiumでは指でスクロールできるのに、Firefoxだとできない。

これが結構使い勝手に影響してきて、最近はChromiumばっかり使ってる。

WordPressのWebサイトがデータベース接続確立エラーを出したとき

t2.microでWordPressを動かすつらみ、わかる?

nginx + WordPressとかいうナウくて(?)イケイケ(?)な構成を試した時の覚書
静的ページしか必要ないならStaticPress + S3でいいじゃん……というのはわかった上で

t2.microというところでだいたい察すると思うが、先に結論を言っておくとメモリ枯渇のお話

構成

めちゃくちゃざっくり表すとこんな感じ
f:id:tkscotte:20180420005202p:plain

問題

WordPressで作成したWebサイトを見ていると、ランダムに「データベース接続確立エラー」が発生する

原因

php-fpmの設定がデフォルトのままだった
そのため、php-fpmの子プロセスが増え続け、インスタンスがメモリ枯渇を起こしていた
なお、 t2インスタンスにはswap領域が無い

調査

  • WordPressのDB設定を再確認
  • nginxのログ( access.log および error.log )を確認
  • /var/log/messages を確認

対応

  1. /var/log/messages を確認 -> パイプで繋げて grep -i "Out of memory" と検索すると楽
  2. top コマンド実行後、 Shift + mキーでメモリ使用率が高いプロセスごとにソート -> ここでメモリ使用率が高いサービスのプロセス数確認
  3. ps aux | grep -i "php-fpm" -> 今回の事例ではphp-fpmの子プロセス数が多かったので個数確認

ここでphp-fpmの子プロセスが40個ほどまで増殖していたのが判明

/etc/php-fpm.d/www.conf の設定を変更する

;pm = dynamic
pm = static

;pm.max_children = 50
pm.max_children = 10

あくまで「誰も見ないような規模のWebサイト」の設定なので、状況に合わせて数値を変動させる必要がある

雑感

デフォルトの設定のままにするな
せめて t2.small にしよう

追記
仕事終わりに雑談に付き合ってくれるお姉さんにめぐりあいたい……めぐりあいたくない?

Elastic Beanstalk single containerな環境でのログ問題

引っ越ししたことでメンタルが回復してきたtkscotteです。

Elastic Beanstalk worker tierを最近試す機会があり、そこでちょっとつまづいたところがあったのでとりあえず 雑に 記す。

(何かあっても責任取れないので使うときは注意してね。)

環境

Elastic Beanstalk Worker Tier (single container / docker 17.06.2)

docker container はECR内の docker image で生成

問題点

  • docker container内で生成したアプリケーションログ(独自のやつ)がそのままだと出てこない

-> AWSのコンソールからは設定できない

  • containerのstdoutがjson形式のlogとして溜まり続ける(ローテーションしてくれない)

-> これが一番ヤバい(INFOログをめちゃくちゃ吐くアプリケーションの場合、最悪1週間くらいでディスクフルになるかも)

解決法まとめ

  1. docker host の /var/log/fugafuga を docker container の /var/log/hogehoge にマウントする
  2. docker host にawslogsを入れる
  3. .ebextensionsでよしなに docker host の /opt/elasticbeanstalk/hooks/appdeploy/enact/00.run を上書きする

実践例

docker host の /var/log/fugafuga を docker container の /var/log/hogehoge にマウントする

Dockerrun.aws.jsonの中に "Volumes" の項目があるので、そこに設定を入れる

{
  "AWSEBDockerrunVersion": "1",
  "Image": {
    "Name": "AWSアカウントID.dkr.ecr.ap-northeast-1.amazonaws.com/リポジトリ名:latest",
    "Update": "true"
  },
  "Volumes": [
    {
      "HostDirectory": "/var/log/hogehoge",
      "ContainerDirectory": "/var/log/fugafuga"
    }
  ]
}

docker host にawslogsを入れる

$ sudo yum install awslogs

ここは他の方法でも良い(後述するけれど、.ebextensionsでもできる)

packages:
  yum:
    awslogs: []

.ebextensionsでよしなに docker host の /opt/elasticbeanstalk/hooks/appdeploy/enact/00.run を上書きする

ソースコード等が入ったデプロイ用ディレクトリのルートに、 .ebextensions という名前でディレクトリを作成

中にpiyopiyo.configみたいなファイルを作り、処理を入れていく

ファイルは content 内の通りに 上書き されるので、十分注意すること

files:
  "/opt/elasticbeanstalk/hooks/appdeploy/enact/00.run":
    mode: "000755"
    owner: root
    group: root
    content: |
~~~~~~↑実際のファイルの中身~~~~~~
      docker run -d --log-opt max-size=100m --log-opt max-file=7 \  
~~~~~~↓実際のファイルの中身~~~~~~

commands:
  "restart_awslogs":
    command: service awslogs restart

環境によっては /etc/awslogs/awslogs.conf の書き換え設定が必要かもしれないので確認が必要。


Elastic Beanstalk、Worker Tier使うのはいいかなーと思うけど、基本的につらみが多い(ヽ´ω`) single containerだとlog driversも選ばせてくれないのも、割とつらかったりする……

誰かのお役に立てれば幸いです。 間違いがあれば指摘もらえるとうれしいです。

参考リンク

docs.aws.amazon.com

docs.aws.amazon.com

docs.aws.amazon.com

aws公式のドキュメントには日本語のページもあるけれど、割りと変な訳になってることが多いので、できれば英語版を読みたい

stackoverflow.com


[追記] 私生活の方でいろいろと励ましてくれるお姉さん募集中です。やさしくされたい。

[追記2] はてなブログってmarkdown記法使えたんだってことに今更気づくなど。 ずっとはてな記法使ってた。

プログレスバーとレストランの待ち時間、そして既読スルー

前職では何かとピザを食べる機会があったなあと、ふと思い出したのでついでに書く。ついでに。特に深い内容でもない。
突然だが、皆さんはドミノピザのピザトラッカーをご存知だろうか。

www.dominos.jp

ネットで注文した後、オーダー受けから配達までの進捗をリアルタイムで見せてくれるサービス。
配達員がどこまで来ているかも、GPSピザトラッカーで確認できる。

ネット上でお買い物を頻繁にする方だと、日本郵便クロネコヤマトなどの荷物追跡サービスがしっくりくるのかもしれない。

クロネコヤマトの荷物お問い合わせシステム

この、「『自分のオーダーが通っているか・どこまで行動が済んだか』というステータスを顧客に見せる」という行為について、
組織としてサービスを提供する側に立った際、考えることがあった。

前職ではエンジニアというよりオペレーターな仕事をしていたので、お客様と連絡を取ることが多かった。
メールや電話、n分おきに鳴り響くアラート……

たとえ障害対応で多忙であったとしても、無応答はマズい。
そこで、依頼された作業がどこまで進んだかをお客様に見せることで、ちょっとした信頼感を得られるのではと少し考えるワケだ。
極論を言うと「メール見ました」というステータスがお客様から見えるだけでも良い。(実際やったらめっちゃ怒られそうだけど)

ただ「◯◯%作業完了しました!」みたいなパーセンテージだけとりあえず見せれば良いというものでもない。
「99%処理完了」とだけメッセージを出し、詳細を見せずに数時間待たされたりするシチュエーションは通じるだろうか。

どこまで、かつ何を見せるようにすれば双方幸せになれるのだろうか。
業種によって見せるものは様々なので、ここで書くのは控えておく。