2016-07-08

【GitBucket】簡単な使い方まとめver2

GitBucket

前回では、ローカルの変更をリモートに反映する方法と
リモートの変更をローカルに反映する方法を説明しました
gamushiros.hatenablog.com

今回はブランチに関してです、早速スタートです

現在のリポジトリの状態はマスターだけが存在する

とりあえずbanchを作成する（branchを切る、とも言います）

$ git branch future-plans

そうすると、状態的には以下のようになる

現在の作業対象のbranchはmasterのため、先ほど作成したブランチに変更する
コマンド実行後はブランチが「future-plans」に変わりました、と出てきます

$ git checkout future-plans 
Switched to branch 'future-plans'

branchが変更されたイメージは以下

ローカル側のstationlocationsファイルに上書きをする

<p>Bitbucket has the following space stations:</p>
<p>
    <b>Earth's Moon</b><br>
    Headquarters
</p>
<p>
    <b>Mars</b><br>
    Recreation Department
</p>

現在の状態を確認してみる（ver1で確認したので説明は割愛します）

$ git status

ステージングエリアに編集を行ったファイルを適用する

$ git add stationlocations

ステージングエリアに配置したファイルをローカルリポジトリへ配置する

$ git commit stationlocations -m 'making a change in a branch'

その際の状態は以下のイメージ
とりあえず、future-plansブランチでの修正は終了した状態

●masterとfuture-plansを合成する
現在のブランチがfuture-plansであることを確認する

$ git status

合成する際は、合成後にmasterとなるブランチをカレントブランチとする

$ git checkout master

合成する

$ git merge future-plans

その際のイメージが以下
masterがfuture-plansにおいついた

合成後、古いブランチは削除する

$ git branch -d future-plans

●リモートにpush!!

実行コマンドは以下

$ git push origin master

（※今回はリモートのmasterブランチに、直接pushしていますが、チームでの開発ではmasterブランチに直接pushすることはほぼありません。他の開発者に怒られると思います。とりあえず、適当なブランチをリモートにpush(コマンド例は下記)し、最終的な確認が済んだらプルリクエスト(すみません記事にできていません)する、という流れが一般的だと思います）

$ git push origin hogehoge(master以外のブランチ名)

コミット履歴を確認したり

ファイルのバージョン管理もできる！

2016-07-08

【GitBucket】簡単な使い方まとめver1

GitBucket

GitBucketの簡単な使い方まとめ。
GitBucketの公式チュートリアルを日本語でまとめました。参考にしてください。

●GitBucketの公式サイト
bitbucket.org

まずGitBucketを使用するために上記へアクセスをします。

f:id:gamushiroS:20160814080534p:plain
「Get started for free」を選択し、アカウントを作成します。
アカウントを持っている場合はログインをします。

そうすると以下の画面が表示されます。
この画面がポータル画面です。さて、スタート地点に立ちましたね。
f:id:gamushiroS:20160814080847p:plain

●リポジトリを作成する

リポジトリとは管理対象のソースを保管するバケツであると考えれば良い。
通常、１つのバケツで１つのアプリケーションのソース管理を行う。

リポジトリの作成を行っていく。ポータル画面上のリポジトリ選択する。
選択をするとプルダウンメニューが出てくるので「リポジトリの作成」もしくは「Create repository」を選択する。
（写真は英語版です。日本語版の場合は多少異なるかもしれません）

ダイアログが出てくるので、必要項目を入力する。
今回はチュートリアルに習って作業を行うため、以下のように入力する。

リポジトリはこれだけで完成！
これから今回作成したリポジトリでソースを管理していく。

●リポジトリのソースをローカルに落として作業を行う
ローカルで作業をするためのディレクトリを作成する（どこでも、どんな名前でも良いです）

$ cd ~
$ mkdir repos
$ cd repos

ポータル画面の[Actions]-[Clone]からclone用のコマンドをコピーしてきて、そのままターミナルに貼り付ける

コマンドを実行する（パスワードも聞かれるので現在のアカウントのパスワードを入力）

$ git clone https://emmap1@bitbucket.org/emmap1/bitbucketspacestation.git?_ga=1.257065608.2003681433.1467938465"

GitBucketのポータル画面で作成したリポジトリが、ローカルにコピーされたことを確認する。
これでローカルで作業をすることができるようになった。

$ ls

●ローカルでファイルを作成し、リモートへ反映させる

以下のコマンドを実行し、リポジトリのディレクトリに移動。

$ cd bitbucketstationlocations

とりあえず、なんでも良いのでファイルを作成する。

$ echo "Earth's Moon" >> locations.txt

ファイル作成後に現在のGitBucketの状態を確認する。
GitBucketには現在のファイルの状態を確認することができ、
ローカルのファイルとリモートのファイルで差分があるか、ファイルが新規に作成されたのか、削除されたのか
を確認することができる。
先ほど作成したファイル（locations.txt）の状態を確認すると「Untracked」になっていることがわかる。
これは「locations.txt」は作成されたがローカル内のGitBucket用のステージングエリアにはまだファイルが存在しないことを示す。
ステージングエリアに関して、先ほどリポジトリをリモートで作成し、ローカルにリポジトリをコピー(clone)したが、その際にローカルにもローカル専用のリポジトリが構築される。ローカルリポジトリはファイルの変更をいきなりローカルリポジトリに適用しないためのクッションのような役割をするステージングエリアを持ち、
ファイルの変更はローカルでのファイル編集、ステージングエリアへのファイルの配置、ローカルリポジトリへのファイルの配置という流れで行っていくことになる。

$ git status 
On branch master
Initial commit
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    locations.txt
nothing added to commit but untracked files present (use "git add" to track)

ステージングエリアにローカルファイルを適用する。

$ git add locations.txt

ちなみに、上記のコマンドでは「locations.txt」だけをステージングエリアにファイルを適用しているが
以下のコマンドを行うことで変更したすべてのファイルをステージングエリアに適用することができる
(こっちの方が圧倒的に使用頻度が高い)

$ git add .

ステージングエリアにファイルを適用したら、GitBucketの状態が
「locations.txt」がnewファイルです、commitしてください、に変化する

$ git status
On branch master
Initial commit
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file: locations.txt

ステージングエリアに配置されたファイルをローカルリポジトリに反映する
ここで「-m」はcommitにつけるメッセージなのでわかりやすいコメント程度のものを書く
（そうした方が後で確認した際、このコミットはなんだっけ？とならない）
commitコマンド実行後は、「master」ブランチ（後述）で１つのファイルが変更されました、というメッセージが出てくる。

$ git commit -m 'Initial commit'
[master (root-commit) fedc3d3] Initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 locations.txt

ローカルリポジトリからリモートリポジトリへ反映する
originというのがリモート側のリポジトリで、masterブランチをリモート側に反映することができる
これにより、ようやく開発のチームメンバーはあなたの変更を見ることができるようになる。

$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 253 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0) To https://emmap1@bitbucket.org/emmap1/bitbucketstationlocations.git
 * [new branch] master -> master
Branch master set up to track remote branch master from origin.

ポータル画面の「commit」を確認すると、コミットの状況を確認することができ、先ほどコミットした情報が出力される

「source」を確認すると、先ほどローカルで作成したファイルが存在することが確認できる

●リモートに存在するファイルをローカルへ持ってくる

以下の画面の「new file」をクリック

ファイル名を「stationlocations」とし、syntax modeリストから「HTML」を選択する
ファイルの中身には以下を入力（別にどんなものでも良い）

<p>Bitbucket has the following space stations:</p>
<p>
    <b>Earth's Moon</b><br>
    Headquarters
</p>

コミットをクリックすると以下のような画面に遷移する

リモートで作成したファイルをローカルにコピーする
このコマンドは、他の開発メンバーがソースに変更を加えた際にはよく実施する操作で
なるべく頻繁にリモート側との整合性を取っておくのが良い（と思う）

$ git pull --all
Fetching origin
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://bitbucket.org/emmap1/bitbucketstationlocations
   fe5a280..fcbeeb0 master -> origin/master
Updating fe5a280..fcbeeb0
Fast-forward
 stationlocations | 5 ++++++++++++++
 1 file changed, 5 insertions(+)
 create mode 100644 station locations

ちゃんとファイルを取得できたことを確認する

$ ls

ここまで、ローカルの変更をリモートに反映する
リモートの変更をローカルに反映する手順を説明しました
続きではブランチの説明です（これがGitBucketの魅力！）

続き
gamushiros.hatenablog.com

2016-06-11

【AWS】AWSソリューションアーキテクト#03の自分理解

問題=============================

EBSプロビジョンドIOPS（SSD）ボリュームのボシュームストレージの料金は使用の有無にかかわらず発生しますか。

================================

かかる。これですっごくお金取られたことあるので、絶対に間違いませんよ。。。

プロビジョニングした大きさ（GB/月）で料金が決まり、インスタンスから切断していても請求の対象になる。

ちなみに最小のストレージの大きさは8GB。

問題=============================

一般的にアプリケーションは、結果を処理する前に、要求がエラーを生成したかを確認します。エラーが発生したかどうかを確認するには、AmazonRDS APIからの応答でどのような状態のノードを探せば良いですか。

================================

Errorノードを探すことで要求がエラーを生成したかどうかを確認することができる。

（ここいまいちわからない。）

問題=============================

AmazonRDSのスタンバイのインスタンスはプライマリと同一のAvailavility Zoneになりますか。

================================

この問いに紐づくAWSの記事は以下である。

docs.aws.amazon.com

この記事には、「Amazon RDS は、マルチ AZ 配置を使用して DB インスタンスの高可用性およびフェイルオーバーサポートを提供します。」という記載がある。つまり、複数のAvailavility Zoneに何もしなくてもレプリケーションされる。

問題=============================

IAMは「よくあるポリシー」としてグループにアクセス許可を割り当てるために使用出来る幾つかのポリシーテンプレートが用意されています。

ポリシーテンプレートのうち、すべてのアカウントのリソースにアクセスするための管理者グループの許可を与えるものは次のうちどれか。

================================

この問いに紐づく記事は以下です。

dev.classmethod.jp

答えは、「Administrator Access Policy」である。2番目に権限を持つポリシーは「Power User Access Policy」であり、アカウント管理の権限が排除されている。

問題=============================

RDS DBインスタンスの新規作成中に、アベイラビリティーゾーンを選択したい。どのステップで変更を行うことができるか。

================================

RDS DBを作成したことがないので作成しました。

そうしたところ、

「エンジンの選択」

↓

「本番稼動用か」

↓

「DB詳細の設定」

↓

「詳細設定の設定」

という手順を踏み、「詳細設定の設定」でアベイラビリティーゾーンを選択できました。これは一度やってみるべき。

問題=============================

Wordpress用のインスタンスをアジアパシフィックリージョンに作成しましたが、海外からのアクセスが多いため、海外のリージョンへ移行することを検討しています。インスタンスを別のリージョンへ移行するにはどのようにすればコピーできますか。

================================

AMIを作成して、それをコピーする。

2016-06-11

【AWS】AWSソリューションアーキテクト#02の自分理解

問題=============================

AmazonS3は何の略称ですか。

================================

「Simple Storage Service」の略。へぇなるほど。シンプルなストレージなのね。

問題=============================

他のユーザが所有しているElastic Load Balancingの設定を変更したい。最も適したものを選択してください。

================================

これ、他のユーザが所有していたとしても、クレデンシャル情報を手に入れるだけでCLIもしくはAWSSDK経由で変更を加えることができる。ポータル画面にログインする必要がない。

問題=============================

実行中のインスタンス内からインスタンスIDを表示するにはどのURIを使用しますか。

================================

インスタンスのメタデータを表示するには、以下の呪文。なんでしょうね、このアドレス。。。

「http://169.254.169.254/latest/meta-data/」

【AWS】AWS資格

サンプル問題集1 – AWS WEB問題集で学習しよう

上記のサイトから問題をお借りしております。

当記事では上記のサイトで学習を行うにおいて、補足しておきたい事項などをまとめました。

問題=============================

インスタンスの起動時にマッピング/dev/sdc=noneを指定することによる影響について、最も適したものを選択してください。

================================

この問いに関して、以下のAWSの記事が紐付きます。

docs.aws.amazon.com

ボリュームとインスタンスを紐付ける際には、「/dev/sdc=hogehoge」を指定します。今回はnoneなので、ボリュームとインスタンスを紐づけない、つまりアタッチしない、ということになります。

問題=============================

EC2インスタンスにマウント可能なストレージデバイスはどれか。正しいものを２つ選択しなさい。

================================

選択肢として、「Glacier」「EBS(Elastic Block Store)」「S3」「EFS(Elastic File System)」が挙げられています。

これに紐づくAWSの記事は以下です。

この理解は本家サイトの説明をそのまま引用させていただきます。

・EFS：共有ファイルストレージ(マウント可能)

　数千の同時接続が可能なように設計されている。これは通常NASによって接続される。また、自動で容量の拡張・縮小ができ、課金は使った分の請求。ただし、他のストレージと比べて対障害などに優れていることもあり、価格設定が高め。

・EBS：ブロックストレージ(マウント可能)

　多分インスタンスを作成すると、勝手に作成されるストレージ。アベイラビリティーゾーン内で、自動的にレプリケーションをされる。

・S3：オブジェクトストレージ(マウント不可)

　ここはWebコンテンツを溜める場所であると、認識していたがストレージといえるみたい。しかしながら、このS3のサービス単独でコンテンツを表示したりするため、マウントはされないのだ、と考えると納得がいった。

・Glacier：アーカイブストレージ(マウント不可)

　ここではファイルをアーカイブとして管理する。一定の時間アクセスがなかったデータをアーカイブにしてくれたりするらしいが、一体どころデータがアーカイブ化されるのだろうか。。。

問題=============================

１リージョン内で割り当てることができる、デフォルトのElasticIPアドレスの最大数について正しいものを一つ選択してください。

================================

これに紐づくAWSの記事は以下である。

docs.aws.amazon.com

正解は、５つである。また、確保されたIPアドレスはアカウントに結びつくらしい。この中で、確保はしているものの、使用していないIPアドレスがある場合は課金の対象になる模様。

問題=============================

Amazon CloudWatchを使用してAmazon EC2 インスタンスのCPU使用率が90%を超えたらアラームメールが送信される設定を行いました。無料枠での範囲で使用したい場合の監視の更新間隔は何分ですか？

================================

この問題の答えは５分である。

何がどのくらい無料であるかは、本家サイトの情報を引用させて頂く。

追加料金なしで使用できるメトリック(測定基準とかいう意味)は以下のとおり。

７種類のメトリックス（５分間隔）

・CPU Utilization

・Disk Reads

・Disk Read Ops

・Disk Writes

・Disk Writes Ops

・Network In

・Network Out

３種類のチェックメトリックス（１分間隔）

・Status(Any)

・Status Instance

・Status System

どうやら、いわゆる運用保守チームの行う監視レベルのことは５分間隔で監視を行ってくれる模様。インスタンスの状態などのクリティカルな部分は１分間隔で面倒を見てくれる模様。

問題=============================

AmazonEBSでスナップショットを作成します。バックアップ方式で正しいものを選択してください。

================================

正解は非同期である。

これに紐づくAWSの記事は以下の通りである。

docs.aws.amazon.com

非同期で行います。

2016-06-08

【python】GoogleAPIを利用する

Python Quickstart | Google Calendar API | Google Developers

このサイトを参考にすれば、問題なくクレデンシャルまでは通すことができるけども、apiをインストールする時点で１か所この通りに行かないところがあったので、メモ。

pythonのバージョンが2系だとpipのバージョンが8.1.1までしか上がらなかったので、３系にしてpipのバージョンを8.1.2以上にする必要があった。

2016-06-06

【watson】watsonを導入する

nohdomi.hatenablog.com

	可用性	スループット増	レイテンシ
スケールアップ	-	○	-
Multi AZ	○	-	-
レードレプリカ	-	○	-
プロビジョンドIOPS	-	○	○

mk-toolブログ

エンジニアと家のことをごちゃごちゃと書いてます

【GitBucket】簡単な使い方まとめver2

【GitBucket】簡単な使い方まとめver1

【AWS】AWSソリューションアーキテクト#03の自分理解

【AWS】AWSソリューションアーキテクト#02の自分理解

【AWS】AWS資格

【python】GoogleAPIを利用する

【watson】watsonを導入する