細菌培養とエンジニアリング

細菌研究からエンジニアへ転向した人のブログ

読書メモ「学びを効率が最大化するインプット大全」Part 4

こんにちは。日曜の夕方、家から出て40分くらい散歩をしていたのですが、改めて実家付近で見える景色を見て、いい景色だなと思いました。
実家に戻りたいという気持ちはあれど、今は戻れないと思いながらいますが、どこかで戻れるといいなぁとほんのり考えています。
にしても、この写真見れば見るほどいい写真だなぁ。。撮ったのただのiPhoneだけど。 f:id:kaedemalu:20200521001257j:plain

CHAPTER4 すべてを自己成長に変えるものの見方

観察力を持つこと

視覚から入る情報はかなり大きな比率を占めており、普段歩いている道であったり、いつも会っている人との観察することも情報を得ることであり、話題の一つにもなるので大事である。PDCAサイクルとは別に、OODAループ(Observe、Orient、Decide、Act)というのがあり、視覚から得た情報をもとに行動をしていくことも一つの手段である。観察力を持つことの大事さは、相手の気持ちを読む、視覚からの情報を得る行動を磨くことである。

メモをとる

こまめにメモを取っておくことで、困ったときに見返すことができたり、ひとまず寝かせておくことができる。ひとまずメモしておくことで、外部の記憶媒体に出したことにも、なり、今後どこかで助かる可能性もある。俗に言う「寝かせる」という言葉に当たるわけですが、あれやりたい、とかこれよさそう、といったメモは将来的に役立つ可能性がある。そのメモに気付くためには何回か見返してインプットしておくことも大事。

視覚情報あれこれ

普段ある周囲から情報を得ることももちろんだが、その他にも情報を得られるものがある。これまでの章でも出てきたが、感情+インプットはより記憶として残りやすい傾向にある。俗にいう芸術(ここでは、映画、絵画、音楽)があるが、想像力を育むことも言われており、IQとは別のファクターで子どもの成長に寄与していることがわかっている。また、休憩の時に「見ない」という選択肢も取れるとよい。なぜなら、目を開けている限り常に視覚情報は入り続けているためで、脳を休ませるためには必要である。

CHAPTER5 最短で最大効率のインターネット活用術

情報を得る

普段何気なくネットサーフィンをしているが、これは明らかに効率が悪く、時間の浪費が激しい。また、インターネットに出回っているものは数多く、一つの話題でも複数存在しているため、ソースを吟味する必要がある。情報の正確性を上げるためにできることは、専門家の発信の情報を見ることなどでカバーできる。

必要な情報だけ

私たちが普段ネットで情報を得る時、必ずといっていいほど、検索サイトを使っており、その時に本当に求めていた情報に1発でたどり着くことは意外と難しく、そこで時間も使ってしまう。なのでRSSなどを使って自分の元に情報が「やってくる」仕組みを作ると時間も節約でき、さらに精度も高くなる。また、はじめから専門性の高いサイトを利用しても正確性は増す。しかし、それでも検索を使うときは高度な検索をして、求めていたものが1ページ目に来るようにすること。
ニュースも、得るときはテレビが多いが、ニュースサイトで自分が必要な情報を得たほうが、メンタルヘルス的にもよく時間の節約になる。

ストックする

ネットの情報はストックしやすいため、EvernoteやPDFにして保存したりなど、どこかに行ってしまわないように保存し、あとで見返しやすくなるようにラベルやタイトルはしっかりしておく。画像でスクリーンショットもメモの一種なので、保存をうまくすることでいいストックになる。

まとめ

今回は4章読んだ日に出せなかったので、まとめました。読めば読むほど、言われていることだよね、改めて言われなくても、みたいな内容ですが、それでも再認識するという意味ではいい機会になっているんじゃないかなと思います。観察力の部分でいうなら比較的養っているとは思うが、情報との付き合い方はまだうまくないから、身に付けたいところ。

読書メモ「学びを効率が最大化するインプット大全」Part 3

はじめに

今回は「学びを効率が最大化するインプット大全」のメモ第三弾です。今日も朝30分読んでから仕事を始めて、夕方になってこの記事書いています。ブログだと自分が何か書いた跡が残るからいいですよね。

CHAPTER3 学びの理解が深まる話の聞き方

本を読むこと、話を目の前で聴くこと

本を読むときは、視覚で文字と図などから情報を得ますが、人からセミナーなどで話を聴くときには、人の動き、癖、表情から受け取るものもあります。本を読む以上に得られる情報があるので、その分記憶に残りやすい。また、より緊張感を持って聴くことで、あとで質問されても答えられたりすることができる。本を読むときもそうであるが、話を聴くときも目的を持って聴くことで、効率が上がる。

「きく」ということ

きく、という行為では傾聴という言葉があり、人とのコミュニケーションの上ではかなり重要になってくる。共感なども、自分の立場からの理解ではなくて、相手の立場からの理解ができているか確認するとよい。会話の中で、男女の感覚の違いというのもある。よく言われるが、男性がアドバイスが欲しくて、女性は共感を求める。パートナーが一番身近な例ではあるが、それ以外にも異性と接するときは気をつけておきたいところである。

きき方

今までは本は「読む」であったが、最近はオーディオブックなどで、本を「聴く」ことができるようになってきた。オーディオブックならスキマ時間や歩いている間でも本に入り込めるので、本を読んだと同じ効果になる。また、時間も節約できる可能性がある。聴くものは、音楽も同様である。音楽には様々な効果があることはいうまでもないが、ジャンルやタイミングで、体内で分泌されるものまで変わってくる。インプットするときに音楽を聴くとマルチタスクに当たるため、効率が落ちてしまう。一方、アウトプットの時間などは併用することで集中力もあげることができる。

まとめ

今回はきくことに焦点が当たっていたが、セミナーに行く意味などを再度確認できたかなと思います。私は、講師に聞けるとかあるので、少人数のものが好きですが、大人数であっても気になったら聞くように努力しています。また、オーディオブックは意義を知れたので、今後使うタイミングがあったらぜひ使いたいなと思いました。当面はYouTubeとかをオフラインで聴くことがメインになるとは思いますが。
回を追うごとに少しずつ書く量も増えてきていい感じになってきました。でも、ハードルはあげないようにしないとですね。

学び効率が最大化するインプット大全

学び効率が最大化するインプット大全

  • 作者:樺沢紫苑
  • 発売日: 2019/08/03
  • メディア: 単行本(ソフトカバー)

読書メモ「学びを効率が最大化するインプット大全」Part 2

はじめに

今回は「学びを効率が最大化するインプット大全」のメモ第二弾です。最近は会社の先輩を見習って、朝と夕方に仮想通勤時間を30分ずつ設けています。朝は読んで、夕方はアウトプットするという流れでしばらくやっていこうかなと思います。(インプットの本をアウトプットする謎)

CHAPTER 2 科学的に記憶に残る本の読み方

そもそも本を読むことについて

本は様々な学習ツールの中で一番リーズナブルなものである。何かを学ぶ時には本を探すことから始めよう。とはいえ、本を選ぶ際にできれば読んで価値の高い本を読みたいので、入門書を読んでからレベルの高い書籍を読む、ネットのレビューや大手書店の棚に平積みされている(レコメンドされている)書籍を手に取ることもより良い本に出会う確率を高める。

読む本のバリエーション

本を選ぶ時、視点の異なる書籍を選ぶことで、一つの意見に偏った知識を持たずにいろんな視点から他の人に説明することができる。読む本の種類も、ビジネス書、技術書ばかりではなく小説も読む。小説にはビジネス書とは異なった色があり、文章から場面を想像する力や、主人公や他の人の疑似体験もできるという点もあるので小説は読むべきである。

読み方、読むツール

本を読む時、先頭から順番に読んでいくと途中で折れてしまう事が多々あるが、それを解消するために、目次を見て、「その本で得たいもの何か」をベースとしていくつかトピックを選び、全体を把握してから読むと理解も深まり、流れも掴みやすくなる。現在は紙媒体だけではなく、電子書籍も使えるが、基本的には紙の方が記憶力とか理解力の観点では優れている。しかし、電子書籍も買ってすぐ読めたり、1つの媒体に多くの書籍を詰め込めるなどのメリットもあるので、どちらも一長一短である。

とにかく、本を読もう。

まとめ

改めて感じる点やすぐに使いたいポイントが多い章でした。特に、目次から本を俯瞰するところはぜひ技術書でやっていきたいなと思いました。いつも心折れるので。積ん読を早く解消していきたいですね。

大体30分で1000文字くらいかける事がわかったので、明日以降もなんとか続ける事ができそう。とりあえず今は右腕の疲労が謎に多くてタイピングままならないのをなんとかしたい。

学び効率が最大化するインプット大全

学び効率が最大化するインプット大全

  • 作者:樺沢紫苑
  • 発売日: 2019/08/03
  • メディア: 単行本(ソフトカバー)

読書メモ「学びを効率が最大化するインプット大全」Part 1

はじめに

タイトルとは関係ないけど、ブログちゃんと使わないとなって思った次第なので、今後は使っていこうと思いました。自分が思う、思っている「書く」ということについては別で触れるのでその時にでも。

読んだ動機

今、プログラミング言語として、Rustを勉強しています。しかしながら、他の言語でもそうですが、割と身につかないな、頭を素通りしていく感覚に襲われていました。何か変えてみようと、Qiitaに簡単解説メモを書いたり、私が会社で所属しているユニットの勉強会のためにまとめたりすることで、かなり理解が深まったことを感じました。なので、学習の過程のインプットについて知ってみようと思った次第です。

読書メモの更新について

基本的に挫折しない程度に、1章区切りか、2章くらいでまとめておこうかなと思います。なので、各回はとても内容が薄いと思います。実際Facebook投稿でいいかなと思ったくらいなのでw

基本的に10行いかない程度の要約とそれに対する感想をつらつら書いていきます。
今回は1章だけ書いていきます。

さて、本題。
Amazonのリンクはこちら。

学び効率が最大化するインプット大全

学び効率が最大化するインプット大全

  • 作者:樺沢紫苑
  • 発売日: 2019/08/03
  • メディア: 単行本(ソフトカバー)

要約メモ

CHAPTER 1 インプットの基本法

インプットとアウトプットは表裏一体の関係

会話をするときは常にアウトプットも考えながら聴いているのと同じように、インプットとアウトプットは常に同時進行である。また、インプットの段階でアウトプットを考えておく。

目標ありきでインプットする

なんとなくのインプットではなぁなぁになってしまうから、「〇〇の試験に合格する」のような具体性を持った目標のもとインプットする。

情報を精査する

これにはいくつかの軸があるが、 - 量より質 - 得る情報をターゲッティングする が大きな所になると思った。量より質は基本的にどこでも言われることだが、密度の高い情報を得る。また、自分が得たいと思っている物に基づいて、情報を選択して取り込む。この2つはどちらも効率を考えた上でのことである。情報を得る上で、なんとなくの粗読ではなく、しっかりと情報を得ようとする「精読」を心がける。そして、得た内容を脳内に留めて初めてインプットが成立。

まとめ

すっごくさっくりまとめてみましたが、詳しくは本読んでくださいに留まる程度にしました。結局自分が「あ、覚えている」と思った行動は、本の中ではリーズナブルという感じだったので、勉強のあとのアウトプットは続けようと思いました。文字書くのは得意ではないですが、好きです。
ハードル上げずに、まずは書いてみました。今後はフォーマットとか考えていきたいですね。

あと、アウトプット大全の方が先に出ていて、こちらの内容を割と踏襲されている気がしたので、読み終わった段階で、さっと目を通して買うかどうかは考えようと思いました。

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

特徴

  • k8sの開発サイクル
    • バックエンドではskaffold
  • デバッグ
  • クラスター管理
    • podの状況
    • YAMLの修正の可視化
      • 反映させなくてもわかるようになっている
  • テンプレートと編集支援
    • deployment, debugが用意されたテンプレートから作成できる
  • エコシステムとの統合
    • 新規のプロダクトに対してのキャッチアップの時間を削りたい...!
  • GCPとの統合
    • GCPの情報をIDEの中でみることができる
  • 自動で認証情報を登録される(./kube/config)
  • deployの選択肢
    • ワンショットのデプロイ
    • 継続的デプロイ(ソースの変更を検知してデプロイ)
  • GKEだけじゃなくて、EKSやAKSも操作できる!

skaffold

  • k8sアプリをのCDをサポートするCLI
  • クライアントのみでも動作し、プラグイン機構で拡張できる ​

    まとめ

  • k8sの学習コストを抑えつつ、ローカル開発を最大伝に効率化させる

個人的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など特定のハードへのアクセスができない
  • 解決のために
    • Knative
      • k8sクラスタにFaaS/PaaS実行環境を構築
        • OSS(Google発祥)
        • コンテナをサーバーレスライクに使える
        • k8sクラスターのハードウェアリソースが使える(GPU/TPU)
      • building block
        • platform
        • Primitives(use Knative)
          • build
          • serving
          • Events
        • Products
          • SAP
          • Cloud Run
          • Cloud Run on GKE
          • etc

特徴

  • 高速なデプロイ
    • ステートレスなコンテナ
    • 高速に0から無限にスケール
    • 数秒でデプロイ
  • サーバーレスネイティブ
    • コードに集中できる
      • ランタイムの制約がなくなる
  • 高いポータビリティ
    • コンテナベースのため
    • Knativeベースであれば他ベンダーでも使える

2つのCloud Run

  • Cloud Run
    • 完全にサーバーレス
    • 使った分だけ
    • Borgが使われている
    • VPCアクセスできない
  • Cloud Run on GKE

2つの対比としてはこちらがよくわかりやすい(らしい)

リソースモデル

  • Service
    • Cloud Runの主リソース
    • Service毎にエンドポイントを提供
  • Revision
    • デプロイする毎に生成される
    • デプロイされるとリクエストが割り振られる
  • Container Instance

ユースケース

  • 外部サービス公開
  • IAMをつかってプライベートにアクセス
  • 非同期タスク
  • Cloud Schedulerを使って定期的に呼び出す
  • DB接続

なぜ高速にデプロイできるのか

  • gVisorを使っている
  • concurrencyを使ったリソース消費とコストの最適化
    • 1つのコンテナインスタンスに投げられるリクエストの最大数
    • コンテナとかを適切に制御
    • チューニングポイントになる
    • 時間課金の考え方
      • 完全にアクセスがなくなるまで
  • Stackdriverとの連携
    • Monitoring
    • logging
    • error reporting

どうサーバーレスを使い分ける?

  • Functions
    • ソースベース
    • イベントドリブン
  • App Engine
    • ソースベース
    • 1プロジェクトにつき1リージョンの制約
  • Cloud Run
    • コンテナベース
    • ランタイム制約・ロックインなし ​

まとめ

  • Cloud Runはコンテナをサーバーレスに使える
  • 様々な制約がない(言語、ランタイム)

個人的に調べたいToDo

  • gVisor
  • Cloud RunとCloud Run on GKEの対比

AIと量子コンピューターで開く、新たなビジネスの可能性 (ML+量子コンピュータ 実用化が進む世界)

Goovenautsのプロダクト ~MAGELLAN BLOCKS~

  • 機械学習の予備知識なしで高度なデータ分析や予測をできるようにしてきた
    • やりたいことがあれば簡単に機械学習を利用できる
    • 応用例
      • コールセンターにかかってくるコール数の予測
      • コンビニの地域による売り上げ予測
        • これから建てるコンビニがどれくらい売り上げられるか
      • etc...

機械学習を進めると...

  • 機械学習をやればやるだけ、最適化が必要になることがわかってくる
  • 事例が溜まってきて機械学習の応用例がたくさんある
  • 解決した課題の先の課題に業を煮やすことが増えてきた
    • コールセンターのリソース管理までは考えられない

Beyond AI

AI x 量子コンピュータ

量子アニーリングタイプのコンピューター

  • デジタルなコンピューターではない
  • 量子力学を利用し、エネルギーの安定した状態を観測できる装置

課題解決のために

  • 世の中の課題をエネルギー式に変換する
    • 微妙なニュアンスを式で変更することができる
    • 条件を追加したり、除去の追加がしやすい

子どもに繋げる

  • 運営しているTech Parkの子どもたちに簡単にAIを体験してもらえる仕組み
    • scratchにAIの拡張とか入れてより遊べるようにしている
      • 発想がすごい(らしい)

GKEによるコンテナセキュリティの道

  • Ian Lewis

アプリ運用今昔

コンテナを導入する前

  • 特定のサーバーにデプロイ
  • 言語別のパッケージング
  • ファイルコピーしてアプリを再起動
  • ほとんどが手動
  • セキュリティ

コンテナの構成

  • どのサーバーにどのコンテナをデプロイするかk8sに任せる感じ
    • 仮に1コンテナを攻撃されても他のコンテナに移られにくい

      コンテナ導入のメリット

  • コンテナの中身関係なくリリース方法が一緒
  • ステップが少ないので自動運用しやすい

    コンテナ導入によるセキュリティの課題

  • k8sへのアクセス権限の管理
  • ファイアウォール
  • セキュリティの新しい可能性
    • 統一したモニタリング
    • イメージスキャン
    • イメージ署名
    • サービスメッシュ

Googleのインフラセキュリティ

  • 責任共有モデルに示されるように、各サービスに責任分界点がある
    • サーバー自体は物理的に防いだり、一部の社員しかデータセンターに入れないようになっている
    • ユーザーのアカウントは、原則Google社員でもさわれないようになっている(ユーザー側の許可が必要)

アプリのライフサイクルをセキュアに

  • コンテナイメージの変更
  • 脆弱性の有無
  • 運用中のアプリが不正侵入されていないか
  • 正しい権限のユーザー、不正アクセスの有無

CI/CD・ビルド

Google Container Registry

  • Dockerコンテナイメージを保存・管理・保護する
  • 安全なプライベートリポジトリである

デプロイ

Binary Authorization

  • 信頼できるコンテナのみをGKEにデプロイ
    • コンテナのリリース業務標準化
    • 予防的なセキュリティ対策
    • 脆弱性があるものについてはそもそもデプロイできないようにする
    • Docker Hubのイメージも使えないようにすることができる

アプリ運用

GKE Sandbox

  • GKEコンテナのセキュリティをさらに強化
    • 徹底した防御をPodに追加
    • 徹底した防御を簡単に導入
    • 潜在的な攻撃を限定する
  • gVisor

Anthos

  • アプリの最新化(モダナイゼーション)
  • ポリシーとセキュリティを大規模に自動化する
  • 一貫性のある体験
    • オンプレでもクラウドでも環境に整合性を持たせることができる
  • サービスメッシュ
    • アプリとアプリの間にプロキシを立てて、どこからのアクセスなのかをはっきりさせる
    • Istio
      • サービス認証・ポリシー
      • モニタリング
      • トラフィックの制御
      • プロキシとプロキシの間のネットワークは暗号化されて、アプリ間の通信が安全になる

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とはなんぞや」と一回しっかりとした説明を受けてみたいと思い、今回参加しました。

何をやったか

今回は 「アーキテクトデザイン講座」 と銘打った回に参加しました。
以前にこんな記事を書きましたが、こちらは入門編でした。

kaedem-dev.hatenablog.com

会場も、入門編は広い会場でしたが、専門編の講座は全てGoogleのオフィス内で行われています。
あとほかには、

の2つがありました。

感想

今回のは本当にさっくりとした個人的な感想のみを書きます。
結論から言うと、やはり参加してよかったなというのが一番です。
資料のわかりやすさは特に大きく、後日見返してもだいたい何が言いたいのかがわかったり、
紹介された各サービスがどんな経緯を辿ってきたのかも少し分かりました。
(ちなみに社内展開用にまとめたマークダウンは400行を超えるボリュームになりました)
個人的にやっていてよかったと思うのは、AWSのSAAをなんとか取得していたことです。
クラウドの基本思想的な部分はどのクラウドでも通じるものがあると感じており、
実際にそうだと思っています。(厳密にはもちろん違いますが)
AWSGCPを比較した時に、ほぼ対応するサービスがあり、AWS側を知っていることでGCPの理解が進みました。 公式にこんな比較記事もあるので、こちらも参考になりました。
参考:AWS プロフェッショナルのための Google Cloud Platform
今回の一番の収穫は、

  • クラウドごとの比較が少しできるようになったこと
  • GCPについての知識が深まったこと

だと思います。
せっかく知れたので、これを資格にしてしまいたいので、今はGCPのプロフェッショナルクラウドアーキテクトを取得しようと勉強を始めています。

最後に

アンケート書くとノベルティサコッシュもらえました。
かっこいい。

f:id:kaedemalu:20190409005244j:plain

Docker Hubにイメージを上げてみる

2019/08/29 記事更新(imageからpushする方法を追記しました)
こんにちは。 先日、こんな記事を書きました。

kaedem-dev.hatenablog.com

これ自体、自分としてはまだまだ未完なので、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で自分のページに行ってみましょう。

f:id:kaedemalu:20190409002224p:plain
Docker Hub push後

しっかりアップされていましたね!

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