Git
Gitといのうは
分散型バージョン管理
バージョン管理システムといのは
システムファイルの変更履歴を管理してくれるシステム
リポジトリといのうのは バージョン管理システムが使っている変更履歴をまとめたノート
概念
・リモートリポジトリ 開発過程を共有
・ローカルリポジトリ オフラインでの作業可能
ワークツリー(add)→ステージングエリア(commit)→ローカルリポジトリ(push)→リモートリポジトリ
用語 インデックス コミットしたいファイルやファイルの一部を登録するところ ワークツリー 履歴管理を行いたいファイルがある場所 *ベアリポジトリ
*ノンベアリポジトリ
ステージ ワークツリーからコミットしたいファイルやファイルの一部をインデックスに登録すること リセット
*プル
*フェッチ
*リベース
*コンフリクト
*ブランチ
*.gitignore 履歴管理の対象外とするファイルを登録するところ。
マージ 異なるブランチの変更を反映させること ブランチ 履歴管理を枝分かれさせたもの *
*
*
dockerと既存仮想化技術の違い
ハイパーバイザー その上で仮想マシンが動作するソフトウェアで ・ベアメタル型(ハイパーバイザー型):ハードウェア上でハイパーバイザが動作。ハイパーバイザーが直接ハードウェアを制御するため、 高速動作可能 ・ホスト型:ハイパーバイザーが直接ハードウェアの制御を行うベアメタルに比べ動作遅い。 VirtualBoxやVMWareあたりはHost型の仮想マシン。
の上記2種類
物理マシン,仮想マシン,コンテナのイメージ 物理マシン:一軒家 仮想マシン:賃貸マンション(独立性重視) コンテナ:シェアハウス(軽量性重視)
Docker Docker社(旧dotCloud社)がPaas事業で使っていた技術をOSS化したもの
軽量コンテナ環境Dockerとは 2013/3公開。オープンソースプロジェクトで、Git hub上でソースコードが公開されている。 GO言語で書かれている。 コンテナ型の仮想環境を作成、配布、実行するためのプラットフォーム Linuxのコンテナ技術を使っている
Dockerデーモン
dockerコマンドは、コマンド自体(client) + dockerデーモン(server)という構成。 run,build→Dockerデーモンが処理をしてる。
Dockerコンテナ
Dockerイメージから作られて実行される仮想環境 Dockerイメージをrunすることで作成される アプリ本体、必要なライブラリなどをパッケージングしたもの
コンテナの分け方
(Physical server,HostOS,Docker Engine)→bins/libs→PHP →bins/libs→MySQL
Docker Bridge
コンテナがホスト外と通信する場合 NATする必要がある。 Nat:2つのネットワーク間のIPアドレスを中継する技術 グローバルIPアドレス←→プライベートIPアドレスの変換を行う仕組み NATをパワーアップさせたのがNAPT
上記問題を解決するツール ・Weave ・SocketPlane ・Docker v1.7〜
Dockerイメージ
コンテナのファイルシステム、設定をまとめて保存
Dockerイメージ→(build)→Dockerイメージ→(run)→コンテナ
Docker Registryと呼ばれる場所にある
[Docker Registry:Dockerイメージ]→(pull)→[サーバ:Dockerイメージ→(build)→Dockerイメージ→(run)→コンテナ]
Dockerサーバ
コンテナやイメージの管理を行う
Dockerクライアント
ユーザがDockerを操作する際に使うコマンド,GUIツール。Dockerを利用する周辺ツールも含まれる。
Dockerのコマンド
DockerToolboxでインストールした場合はDockerQuickTerminalを起動してコマンド入力。 Docker gor Macでは、「ターミナル」アプリケーションで直接コマンドを入力できる。
Hello Worldの実行
$ docker run hello-world
Ubuntuの実行
$ docker run -I -t ubuntu /bin/bash
Nginxの実行(8080)
$docker run -p 8080:80 nginx
コンテナの一覧
$ docker ps
終了
$ docker kill [コンテナID/名前]
削除
$ docker rm [コンテナID/名前]
詳細確認
$ docker version
Is the docker daemon running?.
docker daemonが起動していない
Docker quick start terminalで起動
Is the docker daemon running?.にまだなる。
一度アンインストールしてみる $ brew uninstall --force docker docker-machine docker-compose Uninstalling docker... (8 files, 52.3MB) Uninstalling docker-compose... (887 files, 9.4MB)
アンインストールされていることを確認 tanaka:~ tanakaakio$ docker --version -bash: /usr/local/bin/docker: No such file or directory
Dockerfile
Dockerイメージの構築方法をコードとして記述するファイル。 元となるイメージや、実行するコマンドを記述。
Dockerの仕組み
Dockerでは、コンテナを実現するためLinuxの機能を利用します。
・スタッカブルファイルシステム ファイルシステムの階層を利用してディスクを効率よく利用
・ネームスペース コンテナごとに名前空間を分ける。 名前空間には、プロセス,ネットワーク,IPC,マウント,ホスト名,ユーザがある。
・cgroups CPU,メモリ,ディスク入出力などのリソース管理をする
Docker の純正ツール
・Docker Engine
Docekr本体とも言える、コンテナ,イメージの管理,実行を行うツール
・Docker Hub(レジストリ)
Dockerイメージを集めたサイト。
・Docker Toolbox Mac,windows上でDockerを利用するためのインストーラ。 VirtualBoxの仮想マシン上でLinux、Dockerサーバを動作
・Docker for Mac Mac上でDockerを利用するためのインストーラ。 VirtualBox不要でMacと統合されていて、Docker Toolboxより便利に利用できる。 VirtualBoxと同時に利用可能
・Docker for Windows Windows上でDockerを利用するインストーラ。 VirtualBox不要でWindowsと統合されていて、 VirtualBoxと同時に利用はできない。
・Kitematic GUI操作でDockerを操作するツール。 Dockerインストール後、タスクバーに表示されるDockerのクジラアイコンをクリック。 Kitematicを選択。ダウンロードサイトに。 Applicationsファイルをダウンロード→アプリケーションフォルダに入れる。
・Docker Machine,Docker Swarm,Docker Compose
クラスタ環境にアプリケーションを展開するためのツール。
Docker Machineは、実行環境を構築、管理。 以前はLinuxでしか動作しなかったから、MacとかWindowsはDocker Machineで VirtualBox上に環境を作り、その上でデーモンやエンジンを動かしてたけど、 今は各プラットフォームに対応してるので、ローカル実行の時は使われない。 古いOSを使ってる時は必要
Docker Swarmは、クラスタ管理。
Docker Composeは、コンテナは1プロセスを立ち上げて利用するので、 複数の機能を提供する場合、いくつかのコンテナが協調して動作する必要が あるけれど、それを簡単にするのがDocker Composeです。
Docker Cloud
ウェブ上で、Dockerホストの管理や、アプリケーションのデプロイが行えるツール。
考え方
・Immutable Infrastructure
サーバ起動後に設定を変更したりアプリケーションをインストールせず、 必要に応じてコンテナを作り直すので、適用忘れやサーバごとに状態が 変わることを避けます。
・マイクロサービス(Micro Service)
軽量かる起動が速いというコンテナの特徴を生かして、 アプリケーション・プロセスなど小さい単位でコンテナを分離するので、 依存関係が減り、開発やアップデートが簡単になる。
・Infrastructure as Code
マシンの状態をコードで記述するという考え方。 コードで記述し自動化することで、ミスを減らして変更・管理が簡単になる。
・DevOps
ソフトウェア開発とマシンの管理を統合し、効率よく開発するという考え方。
メリット
・軽量で高速に起動、停止などが可能 ・コード化されたファイルを共有することで、どこでも誰でも同じ環境が作れる。 ・作成した環境を配布しやすい ・スクラップ＆ビルドが容易にできる ・開発工程の中で使っていた環境をそのまま本番環境に持っていくことも可能 ・Dockerイメージを他の人にも渡して使ってもらうことで、各自の環境のバージョンずれ防止や、開発環境準備の短縮化にもつながる ・新規メンバ参画時のコスト削減や、環境依存問題を減らせる！ ・ゲストOSが不要 ・サイズが小さい ・起動が早い ・高いポータビリティ(必要な部分のみポータビリティを確保するので軽量) ・アプリの高密度化可能(ゲストOS用のリソースが不要=コンテナ数増加可能) ・環境構築手順コード化可能(ブラックボックスを防ぐ)
デメリット ・セキュリティ上の様々な問題を抱えている。 ・ルート権限を必要とするコンテナ実行の仕組みが、致命的な脆弱性に繋がりやすい ・開発スピードが速すぎる(今日入れたバージョンが数ヶ月後には古くなると、メンテナンス,保守性,セキュリティパッチなど不安) ・ライブマイグレーションできない ・ネットワークまわりカオス 従来の仮想化<Dockerとは言い切れない。上位互換ではない
Gunosyが試したDocker投入・検証記 Gunosyはエンジニア25名ほどの会社 900万ダウンロード達成。 2104/4頃からDockerを運用
仮想マシンとは
ホストマシン上でハイパーバイザを利用しゲストOSを動かし、 その上でミドルウェアなどを動かしている。
メリット
デメリット
・仮想化マシンではホストOSとアプリケーションの間に、ゲストOS,ハイパーバイザなどが 介在してるのでオーバーヘッドが大きく環境構築に手間がかかる。 ・起動が遅い ・イメージが大きい
Dockerと仮想マシンの違い
1.仮想マシンではマシン単位の仮想化を行う、コンテナではOS単位での仮想化を行う。 そのため、コンテナは必要なリソースが少なく、非常に高速に起動する。
コマンド
yum(Yellowdog Updater Modified)
yum [オプション] [コマンド] [パッケージ名]
YUMを使用することで、
ディストリビューション(Linuxの配布形態)のパッケージアップデート パッケージの検索 パッケージ削除 パッケージの情報表示
などができるようになる。
homebrew Mac OS X オペレーティングシステム上でソフトウェアの導入を単純化するパッケージ管理システム. yum や apt-get と似たようなもの。 Homebrew はスーパーユーザでコマンドを実行する必要が無く、 一般ユーザー権限で使うことが出来ます。
$ brew list exiftool git libidn2 node wget gettext icu4c libunistring openssl
$ brew search wget ==> Formulae wget ✔ wgetpaste
brew -v Homebrew 1.7.3-29-g3a49146
$ brew update Already up-to-date.
$ brew doctor Please note that these warnings are just used to help the Homebrew maintainers with debugging if you file an issue. If everything you use Homebrew for is working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: You have unlinked kegs in your Cellar
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run brew link on these:
git
$ brew --config (設定一覧) HOMEBREW_VERSION: 1.7.3-29-g3a49146 ORIGIN: https://github.com/Homebrew/brew HEAD: 3a4914664e0b2ce83d9ceb029605c5a40e2f6bc7 Last commit: 3 hours ago Core tap ORIGIN: https://github.com/Homebrew/homebrew-core Core tap HEAD: 3152b0138027def7086a4436d06bb51e0e592d79 Core tap last commit: 3 hours ago HOMEBREW_PREFIX: /usr/local HOMEBREW_DEV_CMD_RUN: 1 HOMEBREW_GIT: git CPU: quad-core 64-bit haswell Homebrew Ruby: 2.3.7 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.7/bin/ruby Clang: 9.1 build 902 Git: 2.15.2 => /usr/bin/git Curl: 7.54.0 => /usr/bin/curl Java: 10.0.1 macOS: 10.13.6-x86_64 CLT: 9.4.1.0.1.1528165917 Xcode: N/A XQuartz: N/A
$ brew info git git: stable 2.18.0 (bottled), HEAD Distributed revision control system https://git-scm.com /usr/local/Cellar/git/2.18.0 (1,488 files, 35.2MB) Poured from bottle on 2018-07-03 at 11:11:46 From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/git.rb ==> Dependencies Optional: pcre2 ✘, gettext ✔, openssl ✔, curl ✘, perl ✘ ==> Options --with-blk-sha1 Compile with the block-optimized SHA1 implementation --with-curl Use Homebrew's version of cURL library --with-gettext Build with gettext support --with-openssl Build with Homebrew's OpenSSL instead of using CommonCrypto --with-pcre2 Build with pcre2 support --with-perl Build against Homebrew's Perl rather than system default --with-persistent-https Build git-remote-persistent-https from 'contrib' directory --with-subversion Use Homebrew's version of SVN --without-completions Disable bash/zsh completions from 'contrib' directory --HEAD Install HEAD version ==> Caveats Bash completion has been installed to: /usr/local/etc/bash_completion.d
zsh completions and functions have been installed to: /usr/local/share/zsh/site-functions
Emacs Lisp files have been installed to: /usr/local/share/emacs/site-lisp/git
yumとhomebrewの違い</u
yumでパッケージと呼んでいたところをHomebrewはfarmulaという
yum install パッケージ名 ☆☆☆☆ brew install formula yum remove パッケージ名 ☆☆☆☆ brew uninstall formula yum update [パッケージ名] ☆☆☆☆ brew upgrade [formula] yum list installed ☆☆☆☆ brew list
$ sudo !!
直前のコマンドをsudo付きで再実行
dockerコマンド
eval
指定した文字列を評価後に連結して、現在のシェルに実行させます。 主にシェルスクリプトや環境設定用のファイルで使用します evalコマンドにはオプションがありません。
プロセス
プログラムを実行する際には、まず動かすプログラムをメモリ上に乗せます。 作業机の上に広げるのです。 この実行中のプログラムひとつひとつがプロセス
プロセスID
マラソン大会のゼッケンみたいなもの プロセスを識別するための番号
phpstorm + xdebugをやってみた
$ vagrant -v Vagrant 2.1.1
PHP Version 5.6.37
o$ php -v PHP 7.1.16 (cli) (built: Mar 31 2018 02:59:59) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
$ httpd -v Server version: Apache/2.4.33 (Unix) Server built: Apr 3 2018 23:45:11
(1)Debug Build がnoになっていることを確認(PHP Version 5.6.37 のinfo) この値がnoならOK
(2)PEARのインストール PEARというのはPHPの拡張ライブラリ。 PEARのパッケージの中身は純粋なPHPスクリプトなので、 ソースコードの確認や改造が行いやすい
a.$ curl -O http://pear.php.net/go-pear.phar インストールスクリプトのダウンロード
b.$ php -d detect_unicode=0 go-pear.phar インストールの実行
c.$ export PATH=$PATH:/Users/USERNAME/pear/bin .bash_profileにパスを追加
d.$ which pear /Applications/XAMPP/xamppfiles/bin/pear コマンドが確認できれば完了
(3)homebrewインストール $ brew -v Homebrew 1.7.3-17-g817b72d Homebrew/homebrew-core (git revision 1b7b3; last commit 2018-09-04)
phpでの開発における開発手法
デバッグとは
プログラムのエラーを訂正したり、 プログラムが想定通りに動くかを確認すること。
phpによくある下記のようなエラーログが出力されたら、デバッグを行う。
E_ERROR:致命的なエラー=>実行が中断される
Warning:警告=>実行は継続するが警告はする
Notice:注意=>実行は継続するが警告葉する
E_PARSE:シンタックスエラー=>実行されない
どんな手法があるのか
それぞれのやり方や特徴
関数(var_dump/print_r)
使い方はvar_dumpの中に変数を入れるだけ。 var_dump(変数)
<?php
$ceo = array('apple' => 'ティム・クック', 'google' => 'サンダー・ピチャイ');
$money = 100;
var_dump($ceo);
var_dump($money);
?>
にすると下記の結果となります。
array(2) { ["apple"]=> string(21) "ティム・クック" ["google"]=> string(27) "サンダー・ピチャイ" } int(100)
array()は、変数の内容がarray(配列)であることを示し、( )内には要素の数が表示されます。 今回はarray(2)なので、2つの配列が変数に入っている事を意味しています。 string()は、変数が文字列であることを示し、( )内にはそのバイト数が表示されます。 int()は変数が整数型であることを示し、( )内にはその数値が表示されます。
また、var_dump()の合わせ技として、exit;という命令もよく使います。 PHPのスクリプトをそこで終了させたい場合は、exit;を使いましょう。
<?php
$ceo = array('apple' => 'ティム・クック', 'google' => 'サンダー・ピチャイ');
var_dump($ceo);
exit;
?>
print_rとの違い
<!DOCTYPE html>
<?php
$data = array("one",2,3,"four");
var_dump($data);
echo "
";print_r ($data);
?>
下記一行目がvar_dumpによる情報、二行目がprint_rで表示された情報
array(4) { [0]=> string(3) "one" [1]=> int(2) [2]=> int(3) [3]=> string(4) "four" }
Array ( [0] => one [1] => 2 [2] => 3 [3] => four )
print_rでは配列であるという情報と、各要素の値だけが表示されています。
PhpStormを紹介します。
Phpstormの主な機能
shiftを2回で簡単に検索できる
画面の分割ができる(window/editor tabs/縦か横かボタン)
ファイルをお気に入り登録する。favorite(view/tool windows/favorite)
エディタの中でターミナルを使う(view/tool window/terminal)
定義元クラス定義や、変数・関数の宣言元へジャンプ
command + B command クリック
ログファイルの確認
PHPのエラーが書き出されるログがありますので、デバッグ時にはこれを確認していく。 ログファイルはphp_info()などで確認できます。 設定のlog_errorsがOnになっていれば、 設定のerror_logで指定されたファイルにログが書き出されます。
Laravel エラーログ
/Users/■■■■/Desktop/laravel2018/storage/logs/laravel.logにエラーログ が書き込まれている。
ver 5.6から、ログに関する設定ファイルが専用ファイルに切り出されました。 /Users/■■■■/Desktop/laravel2018/configの中にlogging.phpが入っている。
ver 5.5以下のバージョンはapp.phpにログ設定を記述します。
エラーメッセージを日本語化する
larval/config/app.php
81行目あたり「'locale'=>'en', → 'locale'=>'ja',にする
＊デフォルトで'ja'になっていた。
FuelPHP エラーログ
ログファイルは、 config.php 内の属性 'log_path' で指定されたフォルダに配置されます。
また、パラメータとして 'log_threshold' 、 'log_date_format' を設定することができます。(FuelPHP公式より)
★log_threshold
FuelPHPには、4種類(error, warning, debug, info)のログレベルがある。
Fuel::L_NONE, Fuel::L_ERROR, Fuel::L_WARNING, Fuel::L_DEBUG, Fuel::L_INFO or Fuel::L_ALL
*記述方法
Log::error("errorログ");
Log::warning("warningログ");
Log::debug("debugログ");
Log::info('infoログ');
*出力レベルの変更
'log_threshold' => Fuel::L_ALL,
★log_path
ログファイルの配置場所 (フォルダが書き込み可能である必要があります) 。
log_fileで指定がない場合、"./YYYY/MM/DD.log" という形式で 1日 1つのログファイルが生成されます。 (デフォルトはnull)
/Applications/XAMPP/xamppfiles/htdocs/■■■■/fuel/■■■■/logs/2018/08に、 日付毎にログファイルが入っている。
設定ファイル
アプリケーションの基本設定は app/config/config.php で設定されています。
Applications/XAMPP/xamppfiles/htdocs/fuelphp-1.7/fuel/app/config/config.php
Xdebugをインストール,設定し、Phpstormを設定する。
どのようにデバッグできるのか
・ステップ実行の設定
不具合の原因を探すために、処理を1行ずつ実行
・var_dumpの出力結果を見やすくする
var_dumpが見やすく改行される
・PHP変数を管理してるzval領域の状態を確認
PHP内部の変数は、すべてzvalと呼ばれるひとつの構造体で表現されている。
/Applications/XAMPP/xamppfiles/include/php/Zend/zend.h
・関数の呼び出し元を特定する
関数に問題が起こって、関数がファイルやクラス、関数から呼び出されていたとして、 どこから呼び出された時に問題が起こっているのかを確認するには、 呼び出し元を特定する必要があります。
・プロファイリングができる
統計情報を収集。実行された関数名、何回その関数が実行されたか、 どの関数の実行にどれくらい時間かかったかという情報。 コードのボトルネックを特定。 どこを修正すべきなのかが明確になる。 有効にするには、php.ini で xdebug.profiler_enable スイッチを Onにする
・リモートデバッグができる
ローカルシステムを使って、 リモートシステム上で実行するアプリケーションをデバッグする事が出来る
・エラー時のスタックトレースを確認
エラーが発生するまでの経緯(どんな処理をどの順番で)が示されており、
スタックトレースを解析することでエラーの発生箇所/発生原因を確認することが可能です。
他のデバッグ手法と比べて何が良いのか
・都度 var_dump(); を書くよりも素早く様々な情報を引き出せるので開発スピードが上がる。 (ログを仕込んだり、echoしたりなどの労力や時間を省く事ができる。)
・qcachegrindと組み合わせる事によって、 プロファイルデータを閲覧できるので、簡単にボトルネックが発見できる。
*使い終わったら設定をコメントアウトしてリロードする。
プロファイルデータのサイズは大きいので放っておくと大変になる。
;xdebug.profiler_enable = 1
;xdebug.profiler_output_dir = /tmp
