【Linux】オレ的git-server(remote_repositry作成)

こんばんわ、市電です。

最近、不幸にも7割作成していたシェルスクリプトを不注意で全削除してしまい、 労力と時間を犠牲にして復元しました。 このような痛ましい事故を防ぐべく、Gitを使ってバージョン管理を決心しました。 まず一歩として、リモートリポジトリ作成からはじめてのpushまでを備忘として残します。

【Server】リモートリポジトリ作成

1.git用ユーザー作成

# adduser [gitユーザー名]

1.リポジトリ作成

# su - [gitユーザー名]
# mkdir [リポジトリ名]
# cd [リポジトリ名]
# git --bare init --shared

【Client】ssh公開鍵設定

$ mkdir -p ~/.ssh
$ cd ~/.ssh
$ ssh-keygen -t rsa
→公開鍵、秘密鍵を作成
$ vim config
→以下の記載を入力
Host gitserver                      ←gitserverホスト
HostName gitserver                  ←gitserverIPまたはホスト名
Port 22                             ←sshポート
User git                            ←ssh接続時に使用するユーザー
IdentityFile ~/.ssh/id_rsa          ←gitユーザーの秘密鍵
$ chmod 600 config
$ cat id_rsa.pub

【Server】ssh公開鍵設定

# vim authorized_keys
→クライアントのid_rsa.pubを追記
# chmod 600 authorized_keys
# cd ~
# chmod 700 .ssh

【Client】プロジェクトをPush

$ mkdir [リポジトリ名]
$ cd [リポジトリ名]
$ git init
$ echo "git test" > readme
$ git add .
$ git commit -m "First Commit"
$ git remote add origin ssh://[gitサーバーHost]/home/[gitユーザー]/[リポジトリ名]
$ git push origin master

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

Gitが、おもしろいほどわかる基本の使い方33〈バージョン管理、SourceTree、Bitbucket〉

【AWS】CloudFormationでのデプロイ方法

AWSを使って検証を行うときに使えると便利なCloudFormation
使い方を備忘として記載

1.AWS標準テンプレートを選択

Amazonが展開しているテンプレートを選択(Launch Stack)をクリックする

docs.aws.amazon.com

 

template URLへ自動的に入力されるのでNextをクリックする

2.テンプレート設定

Stack nameには、テンプレートを使って作成するスタック名を入力
Instance Typeには、EC2のデプロイタイプを選択
※デフォルトではt2.smallが選択されているが、t2.microを選択可能
KeyNameには、EC2で使用するKeypairを選択
SSHLocationは一旦無視。

3.タグ設定

ここでタグを設定することでリソースグループからテンプレートを使って作成されたタグを検索しやすくなる

4.設定値確認

設定値に問題ないようであれば、Createをクリック

5.作成開始

StatusがCREATE_IN_PROGRESSになっていれば、作成中。
ROLLBACK_IN_PROGRESSになっている場合、スタックの設定で誤りの可能性あり
自分は、Keypairを選択し忘れたことでROLLBACKが何度も発生して悩んだ経験あり

 

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

 
Amazon Web Services パターン別構築・運用ガイド

Amazon Web Services パターン別構築・運用ガイド

 

 

【雑記】タスク消化の日々・・・どうやってタスク管理してるの?

諸々あって、VPSで作ってたwordpressを破棄してブログははてブに移行しました。

今月から現場異動がありまして、ストレスが少ない通勤方法を模索中です。

今の現場どんな感じ?

自社からこの質問が来るたびに「うるせーこのやろう」と思うのは私だけでしょうか?

 現場の方々は理解のある方なので、初回はあまり振れるタスクが少ないということで
定時上がりさせてもらってます。(いつまで続くか分かりませんが。。。)

そんな少ない作業時間の中で思うことがひとつ。

上位職の方々・・・作業者のタスク管理してないのでは?というところ。

正直、私もガツガツした看守を付けて欲しいとは思ってませんが、

「あれなんだけど、、、○○さんやって~」が多い気がする。
自分じゃないけど。

少ない時間で現場を見る限り、それなりに大きい案件ってのは分かる。
ただし、目下のタスク処理に目が行ってる気もしてる。

この時点でモチベーションダダ下がりです。

じゃあ、どんな現場がいいのよ?

少し前にいた現場は、自社サービスをメインにいじる現場でサーバーを増設したり、問題が起こったら私が所属してるメンバーで協力して対処するという現場だったのでスケジュールも自分で決めれました。

その上、外から来た人へもそれなりに権限をもらえたので、外部への発注権も承認が降りれば出せるとか変にボトルネックになるところが少なかった。

あと、本人からの申し出があればそれなりにやらしてもらえた。
リーダーが非常に技術面で有能な人だったので、リーダーが触ったことがないものでも
過去事象と突き合わせて、「これ出来ないかな?」とか貴重な意見も頂けた。

歴史は繰り返すではないけど、なんだかんだ過去事象で起きたことに気をつけるのも大事ですし、そういう意見を頂ける環境は非常に貴重だと思いました。

また、この現場に戻りたいなぁと感じる日々。

今後どうするさ?

モチベーションが下がっても結局は仕事ですし、続けたら楽しいことがあると思うので手を動かして技術成長に邁進していきたいと思います。

こんなことを考えてる矢先、この記事を見つけました。

 

sapporo-iju.jp

 私、札幌出身なんですよ。
一時期、何もかも嫌な時期は札幌に帰りたいと思いました。
札幌で同じように自社サービス持ってて、そこのインフラ担当が出来る企業さんに転職できたらどれほど嬉しい事か。。。