Dockerのメリットとデメリット

IT docker 初心者 備忘録

Dockerとは？

  • Dockerは「コンテナ」と呼ばれる仮想的な環境を使って、アプリケーションとその実行に必要なものをまとめて管理する技術
  • これにより、開発環境と本番環境の違いによる問題を減らし、迅速な開発とデプロイを実現

Dockerのメリット

Dockerのメリットは大きく分けて以下

  1. サーバの管理がしやすい（隔離性）：
    • コンテナは互いに独立しているため、あるソフトウェアのアップデートが他のソフトウェアに影響を与えない
    • これにより、安全にアップデートや修正を行うことができる
      • 例：Webサーバーとデータベースサーバーを別々のコンテナで管理することで、Webサーバーを変更してもデータベースに影響を与えることはない
  2. 独立性（複数コンテナの同居）：

    • 1つの物理マシンに複数のコンテナを載せることができ、同じアプリケーションの複数バージョンを同時に実行することも可能

    • コンテナの作成、変更、削除が容易なため、環境構築や変更にかかる手間と時間を大幅に削減

      • 例：同じWebアプリケーションのテスト環境と本番環境を同じサーバー上で同時に実行できる
  3. イメージ化が可能（配布・持ち運びの容易性）：

    • コンテナの状態を「イメージ」として保存し、配布・共有することができる

    • これにより、環境の再現性が高まり、開発者間での環境共有や異なる環境へのデプロイが容易になる

    • Docker Hubというイメージの共有サービスを利用すれば、自分で1から環境を構築する必要はない

      • 例：開発環境で作成したイメージをそのまま本番環境にデプロイできる
  4. コンテナはカーネルを含める必要がない（軽量性）：

    • コンテナはホストOSのカーネルを共有するため、仮想マシンに比べて非常に軽量

    • 起動も高速で、リソースの消費も抑えられる

      • 例：仮想マシンではOS全体を起動する必要があるのに対し、コンテナはアプリケーションとその依存関係のみを起動するため、起動が非常に高速
  5. サーバの玄人でなくても扱いやすい（容易な構築）：

    • サーバの構築をコマンド一つで行えるため、専門知識が少なくてもコンテナを作成できる

      • 例：docker runコマンド一つで、必要な環境が整ったコンテナを起動できる

Dockerのデメリット

Dockerのデメリットは以下

  1. Linux OS依存：

    • DockerはLinuxの技術に基づいているため、基本的にはLinux環境で動作する

    • WindowsやUNIXなどのOSでは、仮想マシンなどを介して動作させる必要があり、パフォーマンスが低下する可能性がある

      • 例：Windows ServerでDockerを使用する場合は、Hyper-Vなどの仮想化環境が必要
  2. 親マシンへの依存：

    • 1つの物理マシンに複数のコンテナを載せている場合、親マシンに障害が発生すると、すべてのコンテナが影響を受ける

    • これは、仮想化技術や共有レンタルサーバーなどでも同様のリスク

      • 対策：親マシンの冗長化やバックアップなどを適切に行う必要がある
  3. 単一コンテナでの利用ではメリットが少ない：

    • Dockerは複数のコンテナを効率的に管理するために設計されているため、単一のコンテナを長期的に使用する場合は、導入のメリットを感じにくい場合がある

    • Docker Engine自体がオーバーヘッドになる可能性がある

  4. セキュリティ面の脅威：
    • 複数のコンテナがホストのリソースやカーネルを共有するため、1つのコンテナの脆弱性が他のコンテナに影響を及ぼす可能性がある

Dockerの使い道

Dockerは以下のような用途で活用できます。

  1. 開発環境の統一： 開発者全員が同じ環境で開発を行うことで、環境差異による問題を回避
  2. アプリケーションのデプロイ： 異なる環境へのデプロイを容易にし、迅速なリリースを実現
  3. マイクロサービスアーキテクチャ： 独立したサービスをコンテナとして管理することで、システムの柔軟性と拡張性を高める

まとめ

  • Dockerは、アプリケーション開発と運用を効率化する強力なツール

  • メリットとデメリットを理解した上で、適切な場面で活用することで、開発効率の向上や運用コストの削減に繋げることができる

Kubernetesのお勉強~9回目~

IT Kubernetes 勉強記録

今日やったこと

学んだこと

Namespaceとkubectl

  • Namespaceの作成
k create namespace <Namespace>
  • Namespaceの削除
k delete namespaces <Namespace>
  • Namespace一覧
k get namespaces
  • 特定のNamespace
k get namespaces <Namespace>

Namespace練習してみた

yamlファイルから作成
  • test用のyaml作成
apiVersion: v1
kind: Namespace
metadata:
  name: test
  • apply
❯ k apply -f namespace-test.yaml
namespace/test created
  • testというNamespaceが作成された
❯ k get ns
NAME              STATUS   AGE
default           Active   8d
kube-node-lease   Active   8d
kube-public       Active   8d
kube-system       Active   8d
test              Active   2m51s
  • Namespace削除
❯ k delete -f namespace-test.yaml
namespace "test" deleted
  • kubectlで作成
❯ k create namespace test-create
namespace/test-create created
  • test-createというNamespaceが作成された
❯ k get ns
NAME              STATUS   AGE
default           Active   8d
kube-node-lease   Active   8d
kube-public       Active   8d
kube-system       Active   8d
test-create       Active   9s
  • Namespace削除
❯ k delete ns test-create
namespace "test-create" deleted

所感

  • Namespaceの作成方法としては管理、運用面を考えるとyamlファイル一択ですね
  • 適当なtestとかだと直接作成した方が早いけど、そんな場面があるんだろうか？

zae-zae.hatenablog.com

Kubernetesのお勉強~8回目~

IT Kubernetes 勉強記録

今日やったこと

学んだこと

Namespaceを分けるメリット

  • PodやContainerのリソースの範囲設定（LimitRange）

    • PodやContainerにメモリ、CPUやストレージの上限、下限を設定
    • ContainerのDefaultのメモリ、CPUの設定

  • Namespace全体の総リソース制限（ResourceQuota）

    • Namespace内のメモリ、CPUの合計の上限
    • PodなどObjectの数の上限

  • 権限（RBAC）管理

    • 特定のNamespace内のリソースに限って権限を付与

2種類のリソース

  • KubernetesのリソースはNamespaceに属しているリソースと属していないリソースに分けられる
Namespaceに属しているリソース
  • Namespace-scoped リソース
    • Namespaceに属しているリソースでNamespace削除時には削除される
    • Namespace内で名前はUniqueである必要がある
      • 例：Pod、Service、Deployment、DaemonSet、StatefulSet
Namespaceに属していないリソース
  • Cluster-scoped
    • 特定のNamespaceではなく、クラスタ全体で使われるもの
    • 同1のクラスタ内で名前はUniqueである必要がある
      • 例：ClusterRole、ClusterRoleBinding、CustomResourceDefinition...

Namespaceに属しているか属していないかはkubectlで確認

  • 属している
k api-resources --namespaced=true
  • 属していない
k api-resources --namespaced=false
  • 補足
    • Docker Desktopに接続
k config use-context docker-desktop
  • 接続確認
k cluster-info

所感

  • PodやContainerのリソースの範囲設定（LimitRange）

    • 設定忘れ、設定ミスの影響を防ぐことができる

  • Namespace全体の総リソース制限（ResourceQuota）

    • 特定のNamespaceだけがリソースを使いすぎないようにできる

  • 権限（RBAC）管理

    • チームごとに特定Namespaceへの権限を付与できる

zae-zae.hatenablog.com

Kubernetesのお勉強~7回目~

IT Kubernetes 勉強記録

今日やったこと

学んだこと

kubernetesオブジェクト作成時の必須フィールド

  • apiVersion
  • kind
    • どの種類のオブジェクトか
      • 例：Pod、Deployment...
  • metadata
    • オブジェクト一意に特定するための情報
      • 例：name、UID、namespace
  • spec
    • 理想状態
      • 内容はオブジェクトごとに異なる

前回作成したyamlファイルの中身を確認

  • 4つの必須フィールドが設定されている
apiVersion: v1
kind: Pod
metadata:
  name: nginx-yaml
spec:
  containers:
    - image: nginx
      name: nginx

Namespaceは目的別、チーム別、環境別で切り分けられる

  • 初期Namespace
    • default
    • kube-system...
  • 特定の目的
    • monitoring
    • frontend
    • backend
  • チーム
    • 〇〇チーム...
  • 環境
    • production
    • development...

初期Namespaceの役割

  • default
    • デフォルトのNamespace
    • 指定しない場合はdefaultNamespaceの下にObjectが作成される
  • kube-system
    • kubernetesのシステムによって作成されたオブジェクトのためのNamespace
      • kube-proxy、coredns
      • metrics-server、kube-state-metrics、node-exporterなどのクラスタの状態を取得する
  • kube-public
    • 認証されていないユーザを含むすべてのユーザが読み取り可
  • kube-node-lease
    • LeaseオブジェクトのためのNamespace

所感

  • Namespaceの役割を押さえておく必要がある
    • まずはdefault、kube-systemだけでも押さえておこう！

zae-zae.hatenablog.com

zae-zae.hatenablog.com

Kubernetesのお勉強~6回目~

IT Kubernetes 勉強記録

今日やったこと

学んだこと

yamlでpodを作成

  • 前回学んだ--dry-runをさっそく使用
kubectl create ns nginx-yaml --dry-run=client -o yaml > pod.yaml

中身はこんな感じで設定

apiVersion: v1
kind: Pod
metadata:
  name: nginx-yaml
spec:
  containers:
    - image: nginx
      name: nginx
  • 作成したyamlファイルを指定してPodを作成
k create -f pod.yaml
  • 出力結果
pod/nginx-yaml created
  • Podを確認
k get pod
  • 無事作成されました
❯ k get pod
NAME         READY   STATUS    RESTARTS   AGE
nginx-yaml   1/1     Running   0          2m2s
  • API Versionも確認
    • ちゃんとv1になってます
❯ k api-resources | grep pod
pods                              po           v1                                     true         Pod
podtemplates                                   v1                                     true         PodTemplate
horizontalpodautoscalers          hpa          autoscaling/v2                         true         HorizontalPodAutoscaler
poddisruptionbudgets              pdb          policy/v1                              true         PodDisruptionBudget

kubernetes runコマンドでpodを作成

  • 同じnginxで作成
k run nginx --image=nginx

出力結果

pod/nginx created
  • Podを確認
    • NAME nginxが作成されています
❯ k get pod
NAME         READY   STATUS    RESTARTS   AGE
nginx        1/1     Running   0          20s
nginx-yaml   1/1     Running   0          6m46s

作成したPodの削除

  • yamlで作成したPod
❯ k delete pod nginx
pod "nginx" deleted
  • kubectl-runで作成したPod
❯ k delete pod nginx-yaml
pod "nginx-yaml" deleted
  • 削除できました
❯ k get pod
No resources found in default namespace.

所感

  • Podの作成自体は凄く簡単にできた
    • 詳細な設定を指定していなければデフォルト値になるみたい

zae-zae.hatenablog.com zae-zae.hatenablog.com

Kubernetesのお勉強~5回目~

IT Kubernetes 勉強記録

今日やったこと

学んだこと

  • リソース作成
kubectl create/delete -f <FileName>

NameSpaceを指定して作成

kubectl create ns <NameSpace>
  • 作成したリソースの確認
kubectl get -f <FileName>
kubectl get ns <NameSpace>
  • リソース削除
kubectl delete -f <FileName>
kubectl delete ns <NameSpace>
yamlファイルのベースを作成できる
  • --dry-runを使用
kubectl create ns <NameSpace> --dry-run=<client or server> -o yaml

例

$ kubectl create ns test --dry-run=client -o yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: test
spec: {}
status: {}
  • 簡単にベースファイルを作成できる
    • 必要に応じて編集するだけだから簡単
kubectl create ns <NameSpace> --dry-run=<client or server> -o yaml > test.yaml
  • --dry-run=clientの出力例
❯ k create ns nginx-yaml --dry-run=client -o yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: nginx-yaml
spec: {}
status: {}
  • --dry-run=serverの出力例
❯ k create ns nginx-yaml --dry-run=server -o yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2023-03-06T11:17:04Z"
  labels:
    kubernetes.io/metadata.name: nginx-yaml
  name: nginx-yaml
  uid: e785e8dc-fe83-4503-84d6-ad9913ab2ec8
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

所感

  • ベースファイルの作成は便利そう

ブロックチェーンゲーム(BCG) 11月収支

BCG NFT ブロックチェーンゲーム

11月はFTXの破綻やその影響でBTC等の仮想通貨の下落があり、改めてリスク管理等は大事だなと感じた月でした。 では、早速11月の収支報告です！

11月の収支(11/1 - 11/30)

放置系
  1. クロスリンク

    • 11月

      • 0.00013367BTC 約308.31円
      • 70.51IOST 約83.69円
      • 0.6800ALGO 約22.89円
      • 0.000057ETH 約9.30円

    • 収支

      • 合計：約424.19円
Walk To Earn（W2E）

  1. BitWalk

    • 11月
      • 0.18027mBTC 約423円

  2. aruco

    • 11月
      • 0.000612ETH 約107.25円

  3. ステラウォーク

    • 11月
      • 4.572656XLM 約56円（ゲーム内トークン：990ジェム獲得）

  4. Walken

    • NFT購入しましたが、まだ稼ぐには程遠い
    • 収支
      • 収入：0円
      • 支出：10000円
      • 全収支合計：-10000円

  5. Aglet

    • まだ稼ぐシステムなし

  6. Sweatcoin

    • 通貨への交換はなし。バウチャー等へ交換可能。

  7. Sweat Wallet

Play to Earn（P2E）

  1. エグリプト

    • レアモン当たらず

  2. ゆびほる

    • ETH等の商品と交換できるまでは暫く時間がかかりそう

  3. JobTribes

    • スカラーデビューしたので来月から変化ありそう
    • ユーザLv.30（MAX）到達したので、初めての給料申請しました
    • 11月
      • 40DEP 約20.57円

  4. METAHORSE（メタホース）

    • 2022/11/15 に正式サービス開始しました
    • 11月
      • $81（11,043円）

  5. MEEET

    • 農場経営ゲーム
    • miniNFTを2体購入(￥20,000)し始めました
    • ある程度NFTを育てないと稼げないため育成中です

ローンチ前（ベータ版に参加中のもの）

  1. SleeFi

    • 寝て稼ぐがコンセプト

  2. Kawaii Trump NFT（KTN）

    • NTRトランプゲーム

  3. xtrip

    • M2E

  4. Star Network

  5. De:Litheφ

    • P2E
      • 収入：0円
      • 支出：67,689円
      • 収支合計：-67,689円

zae-zae.hatenablog.com