あじちゃんのブログ。備忘録。

〜エンジニアもOLなんですかね?

php.ini の場所を探すコマンド

php.ini の場所を探す時のコマンド

phpbrew とかを入れていてもこれで検索できる。

 

$ php -i | grep php.ini

Configuration File (php.ini) Path => /Users/{username}/.phpbrew/php/php-7.1.33/etc
Loaded Configuration File => /Users/{username}/.phpbrew/php/php-7.1.33/etc/php.ini

 

phpbrew: システムデフォルトバージョンの切り替え

phpbrew をインストールしたものの切り替えを間違えていた。

use と switch があったのだけれど、help のとおりsystem 全体に適用するには switch を使うこと。

現在のディレクトリだけに一時的に適用するなら use を使う。

 

use    Use php, switch version temporarily
switch    Switch default php version.

 

# 例
phpbrew use php-7.2.9

 

phpbrew known で json_decode() 云々のエラーが発生する

$ phpbrew known

を実行すると以下のようなエラーが発生しました

PHP Fatal error: Uncaught Error: Call to undefined function PhpBrew\json_decode() in phar:///usr/local/bin/phpbrew/src/PhpBrew/ReleaseList.php:50

 

解決の参考にしたサイト: https://github.com/phpbrew/phpbrew/issues/970

 

サイトには以下のように書かれていましたが、私の場合実行すると autoconf が足りないというエラーが出たので先に autoconf を入れることにしました

solved

phpbrew ext install json worked for me

 

$ brew install autoconf

 

$ phpbrew ext install json

 

再度実行すると、ちゃんと表示されるようになりました

$ phpbrew known
# WARNING: ctype extension might be required for parsing yaml file.
Read local release list (last update: 2020-02-26 11:05:46 UTC).
You can run `phpbrew update` or `phpbrew known --update` to get a newer release list.
7.4: 7.4.3, 7.4.2, 7.4.1, 7.4.0 ...
7.3: 7.3.15, 7.3.13, 7.3.12, 7.3.11, 7.3.10, 7.3.9, 7.3.8, 7.3.7 ...
7.2: 7.2.28, 7.2.27, 7.2.26, 7.2.25, 7.2.24, 7.2.23, 7.2.22, 7.2.21 ...
7.1: 7.1.33, 7.1.32, 7.1.31, 7.1.30, 7.1.29, 7.1.28, 7.1.27, 7.1.26 ...
7.0: 7.0.33, 7.0.32, 7.0.31, 7.0.30, 7.0.29, 7.0.28, 7.0.27, 7.0.26 ...
5.6: 5.6.40, 5.6.39, 5.6.38, 5.6.37, 5.6.36, 5.6.35, 5.6.34, 5.6.33 ...
5.5: 5.5.38, 5.5.37, 5.5.36, 5.5.35, 5.5.34, 5.5.33, 5.5.32, 5.5.31 ...
5.4: 5.4.45, 5.4.44, 5.4.43, 5.4.42, 5.4.41, 5.4.40, 5.4.39, 5.4.38 ...



Google Cloud Anthos Day のメモ

#gc_anthosday

https://inthecloud.withgoogle.com/anthos-day-2001/register.html

 

 

Rehost, Replatform, Refactor

コスト、スケーラビリティ、開発速度

マイクロサービス化

 

Developer eXperience

開発者の働きやすさをより良くする必要があった。

 

これからは少ないリソースで効率の良い開発が求められています。

 

デジタル化への取り組みが進んでいる企業の文化や風土魅力などにおいて、成果が出ているところと出ていないところのちがい

→社内の風通し(積極的な情報共有)、オープンである、仕事を楽しむ、新しいことにチャレンジする

 


 

 

JEiS 株式会社JR東日本情報システム

取り組みのきっかけ

生産性向上の取り組み

  • アプリケーション開発スピードの向上
  • 将来必ず訪れる人手不足への対応

→コンテナをやってみよう

 

なぜAnthos

効果用のコンテナ基盤→ハイブリッドまj流智クラウドで利用可能

クラスターのコンフィグを複数プラットフォームで管理できる

マイクロサービスの統一テストが可能

 

ハイブリッドコンテナ基盤

→開発(GKE)・テスト(GKE)・本番(GKE)・オンプレ環境(GKE On-prem)などの複数クラスタを一元管理したかった(パブリックとインプレのハイブリッド運用→今後はマルチクラウドを目指している)

 

CI/CDパイプラインでアプリ開発を高速化

GitLab(ソースコードの管理)→CI/CD(テスト実行、イメージビルド)→各環境へのデプロイ

 

GCPやオンプレミスのHA機能で可用性を高める

ノードやPodのオートスケール機能を活用

クラスタの設定値をコード化してGitLabで保管

 

NextStep

  • ナレッジを社内に展開
  • アプリケーションのモダナイズ化

 

福岡ファイナンシャルグループ

デジタルネイティブ世代の考え方や行動が違う、彼らから見た銀行の価値は我々とは違うのでそれに合わせた姿に変わっていく必要がある。銀行機能をゼロから再定義する。

その銀行を利用すること自体がオシャレだとか利用している自分に満足できるという感覚を提供。

→求められるもの

  • 並行して走れる開発プロジェクトの量
  • DDD
  • マイクロサービス化
  • リリースまでの開発の速さ
  • 世の記述への追随の速さや容易さ

フルクラウド化は情報会計コールセンターなど全てにおいて行う

 

ITガバナンスとエンジニアとの間に溝を作らないようにする。フラットな関係であるように。

 


 

次の10年のために、「Anthos」は共通言語へ

 

Deep-dive into Anthos on GCP

モダナイゼーションを目指すためのAnthos

 

コントロールプレーンとデータプレーンが同居しないことでセキュリティ面で強くなる

 

 

mTLS証明書ベースの認可認証サービス

 

Cloud Run for Anthos:kubernetesよりもシンプルにコンテナを利用できる

アクセス数によって、マシンの使用効率を上げたりとか

 

Cloud Run はインフラ部が見えない。for Anthos のほうが自由度が高い。

 

 

CPG メーカーのアサヒグループがコンテナ運用を始めた本当の理由

古い企業である。シェアは大きい。しかし、新しい市場において新しい消費者を得る必要がある。

 

なにもない。

 

Kubernetes と推し進める、モダンなソフトウェア開発ライフサイクル

 

なぜモダナイズするのか

  • システムが複雑で変更がしづらい。→リリーススパンが伸びる→見積もりがずれる→ボトルネックが発生

 

 

  • カスタマーフィードバックを早く得る→レスポンスを早くする
  • アイディアを投入するまでの時間を短くする

 

モダナイズに必要な方法論目標とする状態

  • イムリーな市場等縫う→ビジネス規模に合わせた拡張
  • これがサービスごとに影響なく改善し続けられる状態

 

コンテナ化だけではアジリティ・フレキシビリティはそんな変わらないよ

 

開発プロセス

  • 開発〜承認プロセスなどを計測→ボトルネックから改善→スループットを以下にあげるか(ばりゅーするーまっちんぐ?)
  • 計測した上で改善を続ける

 

CI/CD(自動化)

  • 手動から自動化へ
  • 暗黙知から形式知
  • ソフトウエアに合わせたライフサイクルの最適化

 

組織とアーキテクチャのでカップリング

  • 組織の分割
  • システムを設計する組織は、組織の構造をそっくり真似た構造の設計を生み出してしまう
  • チームと組織川を機動的に進化させる
  • レガシーシステムの前にファサードをおいて、古いものの一部機能を新しいものとして作る。古いものには手をつけない。
  • 新しい方にリクエストを投げていく
  • 最終的に新しいものだけにできる
  • Anti-corruption layers Pattern(腐敗防止層)
  • 古いインターフェースを新しいインターフェースにするためのレイヤーを作る

 

運用改善

  • 可用性100%を目指すべきではない
  • 莫大なコスト
  • システムの硬直化
  • ServiceAvailabilityが上がればコストも上がる
  • エンジニアだけでなく組織とアーキテクチャの間を考える
  • ビジネスと可用性のバランスを取る

 

  • エラーバジェット = 100% - <可用性の目標>
  • 予算を超えない限りは自由な予算

 

GCPを活用したライフサイクルカップリングの開発をどう回すか

  1. 設計
  2. 開発
  3. ビルド、テスト
  4. デプロイ
  5. モニタリング

 

管理コストの削減

  • マネージドコンテナ基盤

Google Kubernetes Engine(GKE)

  • マスタ管理はGoogleが行う
  • ノード管理もGoogleが行う(upgrade, scale, auto repair)
  • 権限管理
  • 監視やログの管理などをGCP連携できる

Cloud Run

  • 高速デプロイ
  • 高速に 0 to N スケール
  • サーバレス・ネイティブ
  • サーバ管理の必要がない
  • 言語やライブラリの制約がない
  • 使った分だけの支払い
  • 高いポータビリティ
  • Knative API の一貫性
  • ロックインの排除

 

 

開発

  • OS、ランタイムバージョンの差異の解決
  • エミュレータを使用することでマネージの挙動を再現できる

 

エミュレータ

Gcloud beta emulators

 

ビルド、テスト

自動化による品質の保証

  • ビルド、テスト、デプロイをマネージド環境で実行できる
  • GitHubのpushやPRのイベントをトリガーする

 

デプロイ継続的デリバリー

  • Cloud Build のトリガーで、GitOpsを実現

 

モニタリング

Stackdriver Logging

  • リアルタイムのログ監視
  • ログ解析

GKEクラスタのモニタリング

  • CPU/Memory使用率などの細かい指標がみられる

 

継続的な安定運用の実現

SLOを考慮した運用

  • サービスレベル指標を下回った場合にのみアラートを飛ばすような設定が可能
  • SLOの定義は様々→チーム全体で認識を持って取り組む必要がある

 

GKE+Istio+GitOps で作る日経電子版の次世代マイクロサービス基盤

 

日経電子版の開発にGitOpsを利用する

 

課題がある

  • リリースで壊れやすい
  • Microserviceの監視が難しい(サービストチームが多い)
  • 各チームが個別にインフラを頑張っている
  • 運用監視手法や品質がバラバラ
  • サービスの横断的な監視や調査も困難

 

新基盤の目的→SREの下地作り

  • 信頼性の把握と改善

 

開発速度と信頼性の両立

いままで:

  • 改修→レビュー→開発環境→本番環境

問題点:

  • 実際の環境での動作確認ができない。(開発環境では動いてたのに本番環境では動かない(><,)

対策:

  • 確認環境と本番環境の差異を(できるだけ)なくす→staging環境を作る
  • 1branch 1機能検証環境の状態を作る

 

 

 

Domainが違うとcookieの動きか違うなどの差異がある

→リクエストヘッダによってアクセス先環境を分けることで実現する

 

★リリース時はユーザからのリクエストの向き先をstagingに変更して、staging環境を本番環境に昇格する

 

問題が起きたらRoutingを戻すだけでOK

 

Istio で routing を制御する

 

ここでの問題:

  • 本番の負荷・リクエストパターンでしか再現しない問題を検出できない

 

Request Mirroring で本番と同じリクエストをstagingに送る

  • 更新系ではデータ整合の問題がある
  • 他のサービスへ2倍の負荷がかかる場合も...

 

 

シンプルで安全な運用

  • 人為的な事故が起きづらい
  • 事故が起きてもすぐ戻る

 

Kubectl による運用の問題

→学習コスト、操作ミス、運用負荷、変更履歴が追えない、強力な権限が必要

 

↓ これの対策として

 

GitOps

 

  • PRレビューを通じて操作ミスや設定ミスを防止
  • 変更履歴を管理
  • 運用ツールが git, github のみなのでシンプル

 

 

一貫した監視

  • Istio ならサービスに影響を与えずメトリクスを収集でき、監視が可能に
  • Stackdriver によって統一されたモニタリングができる

 

  • 開発に全く関わっていないサービスの調査も可能
  • サービスやチームをまたいだ対応が可能に

 

基盤の安全なメンテナンス

Clusterレベルの Blue/Green で安全にメンテする

  • ArgoCDでBlueと同じ環境のGreenを作る
  • DNSを切り替える
  • Fastlyを解することで本番同様状況を確認できると安全

 

 

GKE で実現する自由な EC サイト構築プラットフォーム

 

Apache + EC-CUBE

 

DB

  • コンテナ(Pod)を利用
  • データファイルはPVに永続化

 

キャッシュサーバ

  • Pod

 

ファイルサーバ

  • Compute Engine

 

CronJob

  • 証明書更新
  • DB/ファイルバックアップ
  • レポート作成

 

1サイトを1NameSpaceで管理

→コンテナイメージは同じだがサイトごとに異なる設定を持つ

 

NetworkPolicyでNS間のアクセスを制御

 

 

  • スケールがサイトごと
  • 自由なカスタマイズを実現
  • NS分離によってサイト間で干渉しない

 

Helm

  • 異なる設定を定義できる

 

 

アップデート

各サイトごとに `helm upgrade` を実行する→Cloud Runで並列化可能

 

Stackdriverによってログを管理、モニタリング

 

その他

コロプラさんの資料

https://speakerdeck.com/inletorder/monitoring-platform-with-victoria-metrics

 

HITACHIさんの資料

https://speakerdeck.com/ido_kara_deru/benefits-and-usage-notes-of-istio-based-on-our-system-operation-experience

 

 

composer を入れる

Composer のインストールは、コマンドを実行したディレクトリで実行・ファイル生成されるので、ホームディレクトリで作業するのをオススメします

以降のコマンドもホームディレクトリで実行したものとして記載しています

 

インストール

Composer の公式サイトで指定されているコマンドを入力

$ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"

$ php -r "if (hash_file('sha384', 'composer-setup.php') === 'c5b9b6d368201a9db6f74e2611495f369991b72d9c8cbd3ffbc63edff210eb73d46ffbfce88669ad33695ef77dc76976') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
Installer verified

$ php composer-setup.php
All settings correct for using Composer
Downloading...

Composer (version 1.9.3) successfully installed to: /Users/{user_name}/htdocs/{project_name}/composer.phar
Use it: php composer.phar

$ php -r "unlink('composer-setup.php');"

 

Version を確認する

$ ./composer.phar -V
Composer version 1.9.3 2020-02-04 12:58:49

 

composer.phar から拡張子を消す

$ mv ~/composer.phar ~/composer

 

パスを通す

ここから2パターン

 

/usr/local/bin/ に置くパターン(管理者権限が必要)

ファイルを移動する

$ mv ~/composer /usr/local/bin/composer

 

元から /user/local/bin にはパスが通っているので実行すれば出るようになる

$ composer -V
Composer version 1.9.3 2020-02-04 12:58:49

 

~/bin/ に置くパターン

ファイルを移動する

$ mv ~/composer ~/bin/composer

 

.bash_profile がなければつくる

$ touch ~/.bash_profile

 

.bash_profile に以下の内容を設定

# [.bash_profile]
export PATH=$PATH:$HOME/.nodebrew/current/bin:$HOME/bin

 

~/.bash_profile の内容を適用する

$ source ~/.bash_profile

 

実行すれば出るようになるはず

$ composer -V
Composer version 1.9.3 2020-02-04 12:58:49

 

GitへのSSH接続時の設定など

SSH接続を2方向にするやつ。当然だけど、設定後 clone は ssh を使うこと!

 

[秘密鍵の生成] ファイル名、私は個人のユーザ名(asahina-dev)とcompanyで分けている

$ ssh-keygen -t rsa -C "your_email@example.com" -f "{file_name}"

 

[公開鍵のコピー]

$ pbcopy < ~/.ssh/{file_name}.pub

 

[公開鍵を Git に設定]

https://github.com/settings/keys

ここで設定する。余分な改行とかスペースとか入らないように気をつける。

Titleは好きにして良い。わかりやすいもの。自分のPC名とかだとわかりやすいかも。

 

[権限] 

$ ls -l ~/.ssh/
-rw-------  asahina-dev
-rw-r--r--  asahina-dev.pub
-rw-r--r--  config
-rw-------  company
-rw-r--r--  company.pub
-rw-r--r--  known_hosts #これは接続すると自動で追加されるファイル

 

[~/.ssh下の構成]

/.ssh
|--asahina-dev
|--asahina-dev.pub
|--config
|--company
|--company.pub
|--known_hosts #これは接続すると自動で追加されるファイル

 

[~/.ssh/config] ホストがかぶる場合は github.com.hoge とかで名前を分けると良い分けた場合はcloneのときつけ忘れないよう注意

Host github.com
  HostName github.com
  User git
  Port 22
  IdentityFile ~/.ssh/asahina-dev
  TCPKeepAlive yes
  IdentitiesOnly yes
Host {会社のGitnoHost名}
  HostName {会社のGitnoHost名}
  User git
  IdentityFile ~/.ssh/company
  TCPKeepAlive yes
  IdentitiesOnly yes

 

[接続を試す]

$ ssh -vT git@{会社のGitnoHost名}
$ ssh -vT git@github.com

 

SSHのオプションはここを見るとわかりやすい

https://euske.github.io/openssh-jman/ssh.html



Rust のインストール

ここに書いてあることを簡略化して書いています。

 

Rustup をインストール

(Rust 1.14.0 以降はインストール方法が変更されて以下になった...とのこと)

$ curl https://sh.rustup.rs -sSf | sh

Welcome to Rust!

...略...

Current installation options:


  default host triple: x86_64-apple-darwin
    default toolchain: stable
              profile: default
  modify PATH variable: yes

1) Proceed with installation (default)
2) Customize installation
3) Cancel installation
>

これが出たら Enter でOK

 

その後このように出るので

Rust is installed now. Great!

To get started you need Cargo's bin directory ($HOME/.cargo/bin) in your PATH
environment variable. Next time you log in this will be done
automatically.

 

指示に従いPATH を追加(永続的に設定するには ~/.bash_profile に設定すること)

$ export PATH=$PATH:$HOME/.cargo/bin

 

追加せずに確認するとこんな感じになる

$ rustic --version
-bash: rustic: command not found

 

「シェルを設定するにはこれを実行してね」って言われるのでする

To configure your current shell run source $HOME/.cargo/env

 

実行する(永続的に設定するには ~/.bash_profile に設定すること)

$ source $HOME/.cargo/env

 

確認する

$ rustc --version
rustc 1.41.0 (5e1a79984 2020-01-27)

Stable版がインストールされる

 

おわり!