Google Cloud Next 2019 聴講メモ
こんにちは。
先日、Google Nextに行ってきて、何個かセッションを見たので、それらの聴講メモです。
それなりに自分でも理解できた点が多くて、割と嬉しかったのが今回です。
Cloud CodeとコンテナツールでK8sを使った開発を徹底効率化
- 岩成祐樹
- Google Cloud
- カスタマーエンジニア
container or k8s
コンテナを用いた選択肢
- GAE(source base)
- Cloud Run (container base& serverless)
- GKE(container base)
k8sを使ってローカル開発を効率化
- 開発者はコードにフォーカスしたいがやることがたくさんある
- インフラ管理
- OS
- middle ware
- monitoring
- etc...
- インフラ管理
k8sを用いた開発の難しさ
- painful deployment cycle
- ソースの修正のたびに繰り返し作業が発生
- context switch
- ブラウザ、IDE等の移動で生産性↓
- high learning cost
- 全部は把握しきれない(k8s自体の開発がかなり早い)
- チームとして把握していることが望ましいがなかなか難しい
Cloud Code
- コードにフォーカスしてできる
- IDEで一元管理
- deploy
- debug
- Pod管理
- etc
- IDEで一元管理
特徴
- k8sの開発サイクル
- バックエンドではskaffold
- デバッグ
- クラスター管理
- podの状況
- YAMLの修正の可視化
- 反映させなくてもわかるようになっている
- テンプレートと編集支援
- deployment, debugが用意されたテンプレートから作成できる
- エコシステムとの統合
- 新規のプロダクトに対してのキャッチアップの時間を削りたい...!
- GCPとの統合
- 自動で認証情報を登録される(./kube/config)
- deployの選択肢
- ワンショットのデプロイ
- 継続的デプロイ(ソースの変更を検知してデプロイ)
- GKEだけじゃなくて、EKSやAKSも操作できる！
skaffold
個人的ToDo
- skaffold
Cloud Run ~Knativeを使った新しいサーバーレス
そもそもserverlessって?(Googleの定義)
- no infra management
- インフラの管理はユーザーでは行わない
- fully managed security
- Google側でセキュリティ問題が完結している
- pay only for usage
- 従量課金制
googleのサーバーレスコンピュート
- Functions
- App engine
- Cloud Run
why Cloud Run?
- Cloud Run以外で起こる問題点
- 使用できる言語、ライブラリに制約
- ベンダーロックイン
- GPU/TPUなど特定のハードへのアクセスができない
- 解決のために
特徴
- 高速なデプロイ
- ステートレスなコンテナ
- 高速に0から無限にスケール
- 数秒でデプロイ
- サーバーレスネイティブ
- コードに集中できる
- ランタイムの制約がなくなる
- コードに集中できる
- 高いポータビリティ
- コンテナベースのため
- Knativeベースであれば他ベンダーでも使える
2つのCloud Run
２つの対比としてはこちらがよくわかりやすい(らしい)
リソースモデル
- Service
- Cloud Runの主リソース
- Service毎にエンドポイントを提供
- Revision
- デプロイする毎に生成される
- デプロイされるとリクエストが割り振られる
- Container Instance
ユースケース
- 外部サービス公開
- IAMをつかってプライベートにアクセス
- 非同期タスク
- Cloud Schedulerを使って定期的に呼び出す
- DB接続
なぜ高速にデプロイできるのか
- gVisorを使っている
- システムコールを阻害
- concurrencyを使ったリソース消費とコストの最適化
- Stackdriverとの連携
- Monitoring
- logging
- error reporting
どうサーバーレスを使い分ける？
- Functions
- ソースベース
- イベントドリブン
- App Engine
- ソースベース
- １プロジェクトにつき１リージョンの制約
- Cloud Run
- コンテナベース
- ランタイム制約・ロックインなし
まとめ
- Cloud Runはコンテナをサーバーレスに使える
- 様々な制約がない(言語、ランタイム)
個人的に調べたいToDo
- gVisor
- Cloud RunとCloud Run on GKEの対比
AIと量子コンピューターで開く、新たなビジネスの可能性 (ML+量子コンピュータ 実用化が進む世界)
- 最首英裕
- Groovenauts CEO
- 世界で唯一商用ベースで量子コンピューターを使っている会社
Goovenautsのプロダクト ~MAGELLAN BLOCKS~
- 機械学習の予備知識なしで高度なデータ分析や予測をできるようにしてきた
- やりたいことがあれば簡単に機械学習を利用できる
- 応用例
- コールセンターにかかってくるコール数の予測
- コンビニの地域による売り上げ予測
- これから建てるコンビニがどれくらい売り上げられるか
- etc...
機械学習を進めると...
- 機械学習をやればやるだけ、最適化が必要になることがわかってくる
- 事例が溜まってきて機械学習の応用例がたくさんある
- 解決した課題の先の課題に業を煮やすことが増えてきた
- コールセンターのリソース管理までは考えられない
Beyond AI
AI x 量子コンピューター
量子アニーリングタイプのコンピューター
課題解決のために
- 世の中の課題をエネルギー式に変換する
- 微妙なニュアンスを式で変更することができる
- 条件を追加したり、除去の追加がしやすい
子どもに繋げる
- 運営しているTech Parkの子どもたちに簡単にAIを体験してもらえる仕組み
- scratchにAIの拡張とか入れてより遊べるようにしている
- 発想がすごい(らしい)
- scratchにAIの拡張とか入れてより遊べるようにしている
GKEによるコンテナセキュリティの道
- Ian Lewis
- Developer advocate
アプリ運用今昔
コンテナを導入する前
- 特定のサーバーにデプロイ
- 言語別のパッケージング
- ファイルコピーしてアプリを再起動
- ほとんどが手動
- セキュリティ
- ファイアウォールで守っていたとしても、超えられたら基本的には丸見え状態
コンテナの構成
- どのサーバーにどのコンテナをデプロイするかk8sに任せる感じ
- 仮に1コンテナを攻撃されても他のコンテナに移られにくい
コンテナ導入のメリット
- 仮に1コンテナを攻撃されても他のコンテナに移られにくい
- コンテナの中身関係なくリリース方法が一緒
- ステップが少ないので自動運用しやすい
コンテナ導入によるセキュリティの課題
- k8sへのアクセス権限の管理
- ファイアウォール
- セキュリティの新しい可能性
- 統一したモニタリング
- イメージスキャン
- イメージ署名
- サービスメッシュ
Googleのインフラセキュリティ
- 責任共有モデルに示されるように、各サービスに責任分界点がある
- サーバー自体は物理的に防いだり、一部の社員しかデータセンターに入れないようになっている
- ユーザーのアカウントは、原則Google社員でもさわれないようになっている(ユーザー側の許可が必要)
アプリのライフサイクルをセキュアに
CI/CD・ビルド
Google Container Registry
- Dockerコンテナイメージを保存・管理・保護する
- 安全なプライベートリポジトリである
デプロイ
Binary Authorization
- 信頼できるコンテナのみをGKEにデプロイ
- コンテナのリリース業務標準化
- 予防的なセキュリティ対策
- 脆弱性があるものについてはそもそもデプロイできないようにする
- Docker Hubのイメージも使えないようにすることができる
アプリ運用
GKE Sandbox
Anthos
- アプリの最新化(モダナイゼーション)
- ポリシーとセキュリティを大規模に自動化する
- 一貫性のある体験
- オンプレでもクラウドでも環境に整合性を持たせることができる
- サービスメッシュ
Event Threat Detection
- GCP環境に存在するセキュリティの脅威を検出
- クラウドベースの脅威を迅速に検出
- 業界トップの脅威インテリジェンスを搭載
ユーザー・アクセス管理
Cloud IAM
- ユーザーが何をできるかを細かく指定できる
- 企業のID管理を簡素化
- 適切な役割
- きめ細かいリソース制御
Cloud Security Command Center
- GCP用の包括的なセキュリティ管理とデータリスクプラットフォーム
- クラウドデータやサービスの可視化と制御により脅威を防止
個人的ToDo
- Envoy
- gVisor
- Istio
Cloud OnBoard Tokyo 2019に参加した②
こんにちは
今回は先週の19日(火)に開催されたCloud OnBoardについてさっくり書きます。
そう、さっくり。
受講のきっかけ
これが今回の一番のミソになるかもしれませんが......。
自分のマルチクラウド化を推し進めたくて、というのが一番の理由です。
そのためにAWSのSAAを取得したというのもありますし、AWSについてはこれで終わりではなく、
他のアソシエイトレベルは早めに取得したいところです。
一方GCPはというと、業務では基本的にAWSなので使ったことはなく、
家で個人開発(と言うにも高尚ですが)で簡単にいくつかいじっていて、
加えてJapan Cloud Study Jamsというものに登録してQWICKLABS内で簡単に自習していた程度です。
なので、体系的に「GCPとはなんぞや」と一回しっかりとした説明を受けてみたいと思い、今回参加しました。
何をやったか
今回は 「アーキテクトデザイン講座」 と銘打った回に参加しました。
以前にこんな記事を書きましたが、こちらは入門編でした。
会場も、入門編は広い会場でしたが、専門編の講座は全てGoogleのオフィス内で行われています。
あとほかには、
の2つがありました。
感想
今回のは本当にさっくりとした個人的な感想のみを書きます。
結論から言うと、やはり参加してよかったなというのが一番です。
資料のわかりやすさは特に大きく、後日見返してもだいたい何が言いたいのかがわかったり、
紹介された各サービスがどんな経緯を辿ってきたのかも少し分かりました。
(ちなみに社内展開用にまとめたマークダウンは400行を超えるボリュームになりました)
個人的にやっていてよかったと思うのは、AWSのSAAをなんとか取得していたことです。
クラウドの基本思想的な部分はどのクラウドでも通じるものがあると感じており、
実際にそうだと思っています。(厳密にはもちろん違いますが)
AWSとGCPを比較した時に、ほぼ対応するサービスがあり、AWS側を知っていることでGCPの理解が進みました。
公式にこんな比較記事もあるので、こちらも参考になりました。
参考：AWS プロフェッショナルのための Google Cloud Platform
今回の一番の収穫は、
だと思います。
せっかく知れたので、これを資格にしてしまいたいので、今はGCPのプロフェッショナルクラウドアーキテクトを取得しようと勉強を始めています。
最後に
アンケート書くとノベルティのサコッシュもらえました。
かっこいい。
Docker Hubにイメージを上げてみる
2019/08/29 記事更新(imageからpushする方法を追記しました)
こんにちは。
先日、こんな記事を書きました。
これ自体、自分としてはまだまだ未完なので、Dockerを学び直して出直したいところです。
飲みながら、この記事の話をしていたのですが、
「せっかくならDocker Hubにあげなよ」と言われたので、試しに上げてみることにしました。
事前に必要なこと
おそらく、Dockerを使う人はほとんど登録しているかと思うのですが、
Docker Hubへの登録が必要になります。
済ませている人は次の項目にいきましょう。
今回使うもの
今回使うリポジトリはこちらになります。
kaedemalu/tf_alpha2.0
(今後はゆるゆるとアップデートするのでお待ちください)
イメージを作る
こちらのリポジトリをクローンして、READMEに書いてあるコマンドを一通り打ち込んでください。
打ち込んだあとは、別タブで以下のコマンドを入力して、コンテナがあるか確認してください。
$ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1af3bcfa251d tensor-alpha "bash" 12 seconds ago Up 11 seconds 0.0.0.0:8888->8888/tcp zealous_heyrovsky
CONTAINER IDとかところどころ違うところはあるとは思いますが、だいたいこのように出力されていれば一旦大丈夫です。
上のコマンドを打ったシェルでまた以下のコマンドを打って、イメージの作成を行います。
$ docker container commit 1af3bcfa251d kaedemalu/tensorflow:2.0_alpha sha256:8a121750495d44ee91f8db8c700171606cffd24bae466849a5341629f436f2a9
sha256から始まるものが出力されたと思います。
なのでこれでイメージがあるか確認します
$ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE kaedemalu/tensorflow 2.0_alpha 8a121750495d 57 seconds ago 1.22GB
ちゃんとイメージが作成されていました。
良い感じ。
(でもサイズが重いんだよね、もっと軽くしたい)
Docker Hubにpushする
さて、この記事のミソかもしれないDocker Hubへのpushのときです。
pushする前に上で登録したアカウントを使ってログインします。
$ docker login Authenticating with existing credentials... Login Succeeded
僕は少し昔に多分ログインしていたので、上みたいな結果でしたが、
遠くの記憶ではDocker Hub登録時のアカウント名とパスワードを聞かれたはず。
さて、ログインも完了したので、pushしていきます。
$ docker push kaedemalu/tensorflow:2.0_alpha The push refers to repository [docker.io/kaedemalu/tensorflow] b7995ea98055: Pushed a147495ba5e4: Pushed be4abbc4e820: Pushed ebe897fdbd91: Pushed 23bcd76a34dc: Pushed b57c79f4a9f3: Mounted from library/ubuntu d60e01b37e74: Mounted from library/ubuntu e45cfbc98a50: Mounted from library/ubuntu 762d8e1a6054: Mounted from library/ubuntu 2.0_alpha: digest: sha256:f1afa3fce8bb65356ddf3c82452b24001dc4cec33785887b0e58287e01d6f977 size: 2205
こんな感じでpushできたみたいなので、Docker Hubで自分のページに行ってみましょう。
しっかりアップされていましたね！
imageからpushする方法(追記内容)
docker build まで済ませてください
タグをつける
Dockerfileやdocker-compose.yamlからbuildできたらimageに対してtagをつけます。
tagをつける前のimageの状況としてはこんな感じ
$ docker image ls | grep tensor-alpha tensor-alpha latest b54653024c82 3 months ago 1.21GB
tagをつけていきます。
$ docker tag tensor-alpha:latest kaedemalu/tensorflow:2.0_alpha
これでtagをつけられたので確認してみます。
$ docker image ls | grep tensorflow kaedemalu/tensorflow 2.0_alpha b54653024c82 3 months ago 1.21GB
できていそうですね！
それでは、Docker Hubにpushしましょう。
$ docker push kaedemalu/tensorflow:2.0_alpha
あとは、Docker Hubにimageがあるか確認しましょう。
余談と新たな発見
途中、以下の記事を参考にさせていただいたのですが、そんなこともできるのかと。
DockerImageをDockerHubに登録の仕方
GitHubとの連携できるのは流石に発見でした。
インフラエンジニアにもGithubを草原にできるチャンスが到来したことを夜中の12:30に確信しました。
もちろん登録しました。
僕の書くべきところは書いたので、Githubとの連携は皆さんもリンクを参考にしてみてください。
もう一つDjangoのDockerのリポジトリあるけど、あれ、docker-compose使ってんじゃん......。↓
kaedemalu/django-maria
AWSのソリューションアーキテクトに受かった話
こんにちは。
題名の通り、AWSのソリューションアーキテクトアソシエイトレベルに合格したので、なんか書いていこうと思います。
はじめに書いておきますが、勉強法とかは書きません。（他にたくさんあるから）
なので、ここでは受けるに当たっての僕のモチベーションとか会場の感想を書いていこうと思います。
完全に自己満足の記事になります。
受けようと思ったきっかけ
まず、モチベーションの根底です。
一時期はAWSのソリューションアーキテクトアソシエイト(SAA)を持っていたら、
それなりに強いイメージがありましたが、最近ではこなれてきた感じが個人的にはあります。
しかし、未だ必要であるとされている資格の中ではダントツで上位であり、勤めている会社もパートナー企業になっていることもあり、
クライアントに説明する上でも厚みをつけられるよねってことで取ることにしました。
(あとは取得奨励金でるのd......)
勉強
とりあえず、最近黒本と称されているこちらを買いました。
徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書
- 作者: ??部昭寛,宮?光平,菖蒲淳司,株式会社ソキウス・ジャパン
- 出版社/メーカー: インプレス
- 発売日: 2019/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
(こちらの内容が陳腐化する前に受けたかったというのもあります)
内容はわかりやすく、何回か読むうちに馴染んでいったのでとてもおすすめです。
何回か読んで、それなりにこちらの問題を解きました。
AWS WEB問題集で学習しよう
試験受ける直前になって気づきましたが、後ろから解いたほうがよかったかもです。
(問題の新しさ的に)
最近あったのは侵入テストが最近不要になってしまったので、こんなところは意外と情報をキャッチしておかないといけなさそうでした。
トピック的には大きかったので知っていましたが。
参考：侵入テスト
模試受けた
結果は 76%
まぁ受からなくもないだろうけど、それなりに不安な点数。
受けた問題をよくよく見返したりして、弱点を少し埋めました。
上司からは「余裕じゃん」とか言われていましたが、個人的にはかなり不安でした。
当日のメンタル
受験前日までは「無理！！！！落ちそう！！！！」とかマジで思っていました。
なのですが、前日くらいは流石によく寝ようと思って、8時間くらい寝ました。
そしたら、当日は「受かるんじゃね？」くらいの謎のメンタルに変化していました。
受けた
当日は銀座のテストセンターにしました。
理由は、上司から勧められてたのと、ネットでもそれなりに評判がよかったからです。
実際にホームページもあるので割と安心して受けられました。
開始時間2時間くらい前に着いてしまったので、地下にあるカフェで最後の追い込みと心を落ち着ける作業をして、受けました。
受かった
実際のところ、3周くらい見直して解答を終えました。
アンケートに答えて、結果が出てきます。
覚えでは合格と出ていたのですが、疲れすぎて夢なのかと思っていた時がありました。
数日後、アカウントを確認したらしっかり合格と出ていたので、安心しました。
(スコア見ると1問間違えていたら多分落ちていました)
思ったこと
睡眠大事
とりあえず受けないと受からない
当たり前かつ当たり前な感想ですし、この試験に限った話ではないですが、本当に痛感しました。
実際、1回延ばしましたし、(読みが甘かっただけなんですが)
試験1週間前は毎日2時就寝、7時起きで勉強みたいなかなり張り詰めた生活をしていて、心が枯れかけていました。
メンタル維持にも睡眠て大事だったんだなって思いました。
あれ、それなりに勉強法とか書いてしまった。
TensorFlowのα版が出たのでDockerfile書いた
こんにちは。
つい先日、TensorFlow Dev Summit 2019というイベントがあったそうですね。
（全然キャッチできてなかった）
そこで、TensorFlowの2.0.0 アルファ版がリリースされたとアナウンスされました。
早速試せるみたいなのですが、ここはせっかくならDockerで動かそうと思ったのですが、
思いの外詰むことが多くて、でも個人的には達成感が多いものにもなりました。
なので新鮮な情報を得たので、新鮮なうちにブログにしてしまいます。
はじめの方針
「Dockerのイメージはなるべく軽くすること」がいいことと最近知りました。
ならばAlpineベースで作りたいと思いました。
無知であるがゆえに夢を抱いていましたが、それが蟻地獄への第一歩......。
Alpineベースで試す
公式サイトによると、最終的には
$ pip install tensorflow==2.0.0-alpha0
ができればアルファ版を試せるようになると書いてあります。
ここを最終目標として作ります。
参考は忘れてしまいましたが、最初のDockerfileはこんな感じです
FROM alpine:3.7
RUN apk --update-cache \
add linux-headers \
gcc \
g++ \
make \
openblas-dev \
python \
python-dev \
python3 \
python3-dev
RUN mkdir /app
WORKDIR /app
RUN pip3 install --upgrade pip
RUN pip install Pillow \
ipykernel \
jupyter \
keras_applications \
keras_preprocessing \
matplotlib \
numpy \
pandas \
scipy \
sklearn
RUN python -m ipykernel.kernelspec
RUN pip --no-cache-dir install \
tensorflow==2.0.0-alpha0
(お作法とかが身についていないのは許してください)
こんな感じでDockerfileを書いてみました。
最低限必要なものはapkでインストールし、
そのあとはpipで色々入れて、最終的にTensoFlowをインストールしようとう魂胆です。
蟻地獄その1
あるエラーが出ました。
Collecting matplotlib
Downloading https://files.pythonhosted.org/packages/26/04/8b381d5b166508cc258632b225adbafec49bbe69aa9a4fa1f1b461428313/matplotlib-3.0.3.tar.gz (36.6MB)
Complete output from command python setup.py egg_info:
============================================================================
Edit setup.cfg to change the build options
BUILDING MATPLOTLIB
matplotlib: yes [3.0.3]
python: yes [3.6.5 (default, Aug 22 2018, 14:20:40) [GCC
6.4.0]]
platform: yes [linux]
REQUIRED DEPENDENCIES AND EXTENSIONS
numpy: yes [not found. pip may install it below.]
install_requires: yes [handled by setuptools]
libagg: yes [pkg-config information for 'libagg' could not
be found. Using local copy.]
freetype: no [The C/C++ header for freetype2 (ft2build.h)
could not be found. You may need to install the
development package.]
png: no [pkg-config information for 'libpng' could not
be found.]
qhull: yes [pkg-config information for 'libqhull' could not
be found. Using local copy.]
OPTIONAL SUBPACKAGES
sample_data: yes [installing]
toolkits: yes [installing]
tests: no [skipping due to configuration]
toolkits_tests: no [skipping due to configuration]
OPTIONAL BACKEND EXTENSIONS
agg: yes [installing]
tkagg: yes [installing; run-time loading from Python Tcl /
Tk]
macosx: no [Mac OS-X only]
windowing: no [Microsoft Windows only]
OPTIONAL PACKAGE DATA
dlls: no [skipping due to configuration]
============================================================================
* The following required packages can not be built:
* freetype, png
----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-install-07jytk9b/matplotlib/
The command '/bin/sh -c pip install Pillow ipykernel jupyter keras_applications keras_preprocessing matplotlib numpy pandas scipy sklearn' returned a non-zero code: 1
matplotlibをインストールしている時にでたエラーです。
とりあえずmatplotlibを無視してみても他のインストールエラーが出るので、一旦公式に倣ってみることにしました。
公式に倣う
TensorFlowの公式にDockerfileがありました。
今回はこちらをお借りして、TensorFlowのところまで試しました。
50行目にある、TensorFlowのインストールの部分をアルファ版に置き換えました。
それがこちら。
FROM ubuntu:18.04
# Pick up some TF dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
build-essential \
curl \
libfreetype6-dev \
libhdf5-serial-dev \
libpng-dev \
libzmq3-dev \
pkg-config \
python \
python-dev \
rsync \
software-properties-common \
unzip \
&& \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
RUN curl -O https://bootstrap.pypa.io/get-pip.py && \
python get-pip.py && \
rm get-pip.py
RUN pip --no-cache-dir install \
Pillow \
h5py \
ipykernel \
jupyter \
keras_applications \
keras_preprocessing \
matplotlib \
numpy \
pandas \
scipy \
sklearn \
&& \
python -m ipykernel.kernelspec
# Install TensorFlow CPU version from central repo
RUN pip --no-cache-dir install \
tensorflow==2.0.0-alpha0
こちらで
$ docker build -t tensor-alpha .
を叩くと、一通りbuildできました。
蟻地獄その2
Macローカルではすんなりbuildできて、満足していました。
で、環境をLinuxでもできるかと思ってやってみました。
buildまでは全然できて、コンテナ内にも入ることができました。
コンテナ内のディレクトリにローカルのディレクトリをマウントしているのですが、
それを確認しようよ思ってもpermissionで怒られました。
解決策
コンテナ内に入る時にオプションをつける
$ docker run --rm -it -p 8888:8888 -v $(pwd):/app:Z -w /app tensor-alpha bash
-vのオプションの最後にZをつけると解消されました。
参考：dockerで共有ディレクトリを利用したが、「Permission denied」が出てアクセスできない。
やっとできた
時間はそんなにかかっていないけれど、なんとかインストール済みのimageを作成できてよかったです。
あくまでインストールまでが目標なので、使えるかは不明ですが、チュートリアルにある
このコードは動きました。
今回はDockerfileを書くことまでが目的でしたが、今度は実際にアルファ版を試してみた記事を書いてみたい。
これをやって唯一後悔しているのは、朝の5時まで興に乗って試しまくっていたことです。
睡眠、大事......。
他のリポジトリにpushする時
こんにちは。
今回の記事は誰かの役に立つというよりは、
自分の備忘録的な部分になるので、もし参考になる人がいたら、
コメントとかスターとかつけてもらえると嬉しいです。
扱うケース
今回、扱うケースとしては、
そういう場合でどうすればいいか分かるように書きます。
例えばですが、最近Githubがプライベートリポジトリを無制限に作成可能になったので
以下のユースケースは考えにくいですが、
BitBucketで作っていたものが完成したのでGithubで公開したい
とかが該当するのではないかなと思います。
今回は、開発用のリポジトリと本番環境用のリポジトリがある時を考えてやっていきます。
それでは、始めます。
ステップ
- 現状のリモートリポジトリを確認
- 思い出す
- はっ......さては......
現状のリモートリポジトリを確認
(今回はGIthub、httpsで扱っている時を例にします。)
$ git remote -v
とコマンドを打つと、
origin https://github.com/[user_name]/[repo_name].git (fetch) origin https://github.com/[user_name]/[repo_name].git (push)
上記のように現在登録されているリポジトリが出てくると思います。
思い出す
$ git remote add origin https://github.com/[user_name]/[repo_name].git
と打つように指示がなされていたかと思います。
そして、
$ git push -u origin master
と打つことでソースコードがGit上にpushしますよね。
ここで、全く疑問を感じずに-uとかremote addとかしているとのちに壁にぶち当たるわけですよ。
(僕みたいに)
はっ......さては......
調べて今さら知りました。
リモートリポジトリは名前を変えれば加えられること。
ここでは本番環境のリリースブランチにpushすることを想定するとしましょう。
$ git remote add prod https://github.com/[user_name2]/[prod_repo].git
こうすれば
$ git remote -v
としたときに
origin https://github.com/[user_name]/[repo_name].git (fetch) origin https://github.com/[user_name]/[repo_name].git (push) prod https://github.com/[user_name2]/[prod_repo].git (fetch) prod https://github.com/[user_name2]/[prod_repo].git (push)
と表示されていると思われます。
そして、pushするときは
$ git push prod release
と打てばpordとしたリポジトリのreleaseブランチにpushされているはずです。
書くの忘れた
すっかり書くのを忘れましたが、-uをつけると、push、pullするときにデフォルトのリポジトリとしてみてくれて、
次回から
$ git pull
とかしても-uオプションをつけた方から自動的にpullされるようになります。
まとめ
改めて考えてみたら、「そんなことか」みたいなことですが、案件でinitial commitするのなんてPMかPLくらいですし、
自分でゴリゴリ開発している人の方がずっと理解していそうだなぁと思いました。
考えりゃわかるだろ系記事ですが、備忘録までに......。
パンチの効いた検証を思いついたけど、いろんな意味の学習コストが半端ない。
Cloud OnBoard Tokyo 2019に参加した①
こんにちは。
今日は、2/20(水)に行われたCloud On Boardに参加してきました。
昨年は非常に人気で席が割と早く埋まったとか埋まってないとか...。
たまたまWebで見つけてその場で応募しましたが、心から行ってよかったと思う内容でした。
全体の内容は避けますが、だいたいどんな感じか、ざっくり書いていけたらと思います。
Cloud On Boardとは
そもそもCloud OnBoardってなんでしょうという話です。
Cloud OnBoardとは、
Cloud OnBoard は GCP 認定トレーナーによる Google Cloud Platform (GCP) トレーニング入門編です。
2016年より開催されております とのことす。参考サイト
2016年から開催されているとなると、今回で4年目になるのでしょうか。
なんで行こうと思ったのか
僕がなんでこのイベントへの参加を決めたのかというのを書きます。
新卒でエンジニアを始めて以来、僕はクラウドにとても興味を持ちました。
なのでそれに付随して、ベンダーの資格も取りたいと思い、今は勉強しているところですが、
このCloud OnBoardはGCPの資格を取得された方の記事をみているとそれなりに見受ける言葉でした。
なので、
「そもそもクラウドとは」みたいな考え方から
「GCPはどう使えばいいのか」とかを一度ハンズオンとして聞きたかったので参加しました。
申し込みをしてから、この日がとても待ち遠しくて仕方がありませんでした。
実際に参加した感想
声を大にして言いたい
すごくよかった！！！！！
何がよかったというか、非常にわかりやすい！
GCPの基本的な考え方や、最近流行りの機械学習のネタまで、
GCPのサービスや、始めの立ち上げ方までデモで見せていただいたりもしました。
少し面白かったお話
- 「クラウドはスケールしますが、トイレはスケールしませんので......。」
確かに。
特にエンジニア系のイベントは男性が圧倒的に多いので、
普段女性が並んでいて大変だな、と思う行列に並ぶことになるので少し気持ちがわかるような気がしました。
- 「小学生の夏休みの課題にBig Query」
そういう発想が今後はどこかで訪れるとは思うのですが、個人的にはなかなか好きな話でした。
Big Queryは割と簡単に結果を得られるので、複雑なクエリ投げる必要ありません。
しかし、それは高性能であるからであって、ローカルで行うためにはもっと複雑な
クエリを投げないと大変なことになりますね笑
また、Big Queryしか使っていなかった人が使えない環境に行ったらとても苦しんだ話を聞いたので、
便利に慣れてしまうのも問題だなと思ってみたりしています。
まとめ
今回はGCPを知るためにCloud OnBoardに参加しました！という記事でした。
内容は、GCPの0→1を手助けするようなもので、それなりに知っている人にとっては物足りなかったのかも知れません。
ですが、GCPに限らずクラウドの思想も知れた気がするので個人的には大満足でした。
まだまだ、GCPの知識は全然ないですが、今年中にはGCPの資格取得も目指すので、
これから深めていきます！
また、今回は入門編を紹介しましたが、もう一つ
「アーキテクトデザイン講座」にも参加するので、
そちらの内容も参加後、うっすらと書いていきたいと思います！
追記(2019/05/20)
思いのほか、この記事を見ていただいている方が多いので、
こちらも参考までにご覧ください。
