Upgrade to Pro — share decks privately, control downloads, hide ads and more …

インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」

インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」

インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」登壇資料です。

cyberblack28

May 12, 2022
Tweet

More Decks by cyberblack28

Other Decks in Technology

Transcript

  1. Profile Name • Yutaka Ichikawa/市川 豊 Belong • Oracle Corporation

    Japan • Solutions Architect Role • Principal Cloud Solution Engineer SNS • Twitter/GitHub/Qiita:cyberblack28 Blog • https://cyberblack28.hatenablog.com/ Materials • https://speakerdeck.com/cyberblack28/ Community • Oracle Cloud Hangout Cafe #ochacafe • CloudNative Days Tokyo #cndt2021 #o11y2022 Certified • Certified Kubernetes Administrator • Certified Kubernetes Application Developer • Certified Kubernetes Security Specialist • Kubernetes and Cloud Native Associate Publications New
  2. Agenda • 第1章 コンテナの世界に飛び込む前に • 第2章 コンテナアプリケーション開発に必要なソフトウェア • 第3章 コンテナアプリケーション開発のライフサイクル

    Build・Ship・Run • 第4章 コンテナオーケストレーション • 第5章 Kubernetesでコンテナアプリケーションを動かすまで • 第6章 ローカル開発の準備 • 第7章 コンテナアプリケーションにおけるCI/CD
  3. 第1章 コンテナの世界に飛び込む前に 既存のアプリケーション開発 物理マシン 仮想マシン 仮想マシン(クラウド) コンテナ 物理サーバでアプリケーションを稼働 VM 物理サーバ上に複数の仮想マシンでアプリケーションを稼働

    クラウドをベースとしたスケーラブルな仮想マシンでアプリケーションを稼働 物理マシン・仮想マシンもノードとして束ねて、コンテナという小さい単位 でアプリケーションを稼働
  4. 第1章 コンテナの世界に飛び込む前に アプリケーション コードをソースコードリポジトリに コミット/プッシュ CI/CDパイプラインによる テスト、ビルド、デプロイ Developer Code Repository

    CI/CD Pipeline すべて自動化されている場合もあれば、手動で行う場合もあります。 本番環境 ステージング環境 検証環境 Operator Infrastructure Engineer 開発環境 OS/ライブラリ VM 物理マシン 仮想マシン 仮想マシン (クラウド)
  5. 第1章 コンテナの世界に飛び込む前に OS/ライブラリとアプリケーションの分離 アプリケーション 本番環境 ステージング環境 検証環境 開発環境 OS/ライブラリ VM

    物理マシン 仮想マシン 仮想マシン (クラウド) アプリケーションは物理マシンや仮想マシンのOS/ライブラリ上で稼働 稼働するアプリケーションは実行環境に依存する 環境差異が原因で他の環境で稼働するけど、 本番環境で稼働しない等の障害が発生する OSのパッチバージョンが異なる、このライブラリが無 かった、関係ないものがインストールされている…
  6. 第1章 コンテナの世界に飛び込む前に アプリケーション OS/ライブラリ • 仮想マシンイメージがベンダー製品特有(ベンダー ロックイン) • 容量も重い(数ギガ~数十ギガ) •

    可搬性(Portability)が低い • 運用負荷 Xen Server 仮想マシン イメージ KVM VMWare ハイパーバイザー ハードウェア VMWare Xen/Server KVM 物理/仮想マシンにおける、OS/ライブラリのアップデートには人手 や時間を要するため、アプリケーションのリリースに影響する… 仮想マシン
  7. 第1章 コンテナの世界に飛び込む前に これまでのアプリケーション開発 OS/ライブラリが既に整っている実行環境にアプリケーションをデプロイするという形式 1.アプリケーション • 環境差異による問題が発生 • OS/ライブラリ側に何かあるとアプリケーションに影響 2.インフラ

    • 仮想マシンイメージがベンダー製品特有(ベンダーロックイン) • 仮想マシンイメージの容量が重く可搬性(Portability)が低い • 物理/仮想マシンの特性上、OS/ライブラリのアップデートに時間を要して、アプリケーションのリリースに影響する
  8. 第1章 コンテナの世界に飛び込む前に 仮想マシンとコンテナの違い ハードウェア ハイパーバイザー OS/Hyper Visor OS/Hyper Visor カーネル

    カーネル アプリケーション アプリケーション ライブラリ ライブラリ 仮想マシン 仮想マシン ハードウェア カーネル OS/Hyper Visor OS/Hyper Visor コンテナ コンテナ コンテナエンジン 各仮想マシンのカーネル上で実行、隔離性が高いが、起動 が遅く(数分)オーバヘッドが大きい。 カーネルを共有しているため、隔離性は低いが、起動が高速 (数秒)でオーバヘッドが小さい。 仮想マシン コンテナ アプリケーション アプリケーション ライブラリ ライブラリ
  9. 第2章 コンテナアプリケーション開発に必要なソフトウェア Dockerを構成する主要コンポーネント 1.Image OS/ライブラリ Dockerfile イメージ Build 2.Registry OS/ライブラリ

    イメージ Ship OS/ライブラリ レジストリ 3.Container OS/ライブラリ OS/ライブラリ OS/ライブラリ OS/ライブラリ イメージ Run OS/ライブラリ コンテナ
  10. 第2章 コンテナアプリケーション開発に必要なソフトウェア Dockerで実現するBuild/Ship/Run 1.Build 読み込み専用 (ReadOnly) ベースイメージ CentOS イメージ層 Container

    Image FROM centos:7 RUN yum -y install epel-release RUN yum -y install nginx COPY index.html /usr/share/nginx/html ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;“] Dockerfile ① ② ③ ④ ⑤ ⑤ ④ ③ ② ① $ docker image build Build Dockerfileからビルドして、コンテナイメージを作成する
  11. 第2章 コンテナアプリケーション開発に必要なソフトウェア 2.Ship コンテナエンジン(dockerd) ハードウェア pull コンテナ レジストリ CentOS リポジトリ

    Ubuntu リポジトリ Container Image push tag:latest tag:6.7 ・ ・ tag:latest tag:14.04 ・ ・ Ship Nginx リポジトリ tag:latest tag:19.1 ・ ・ カーネル run build Container Image Container Image $ docker image pull $ docker image push Dockerfile レジストリにイメージのアップロード(push)とダウンロード(pull)して、イメージの共有を行う
  12. 第2章 コンテナアプリケーション開発に必要なソフトウェア 3.Run pull コンテナ Image Registry Container Image push

    Run run build Container Image Container Image $ docker container run Dockerfile ベースイメージ CentOS イメージ層 書き込み可能 イメージ層 Container Image ⑤ ④ ③ ② ① 6 読み込み専用 (ReadOnly) FROM centos:7 RUN yum -y install epel-release RUN yum -y install nginx COPY index.html /usr/share/nginx/html ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;“] Dockerfile ① ② ③ ④ ⑤ コンテナエンジン(dockerd) ハードウェア カーネル イメージをもとにコンテナを起動する
  13. 3章のポイント Build / イメージビルド Dockerfileを作成して、イメージのビルドを行う上で必要となる、Dockerfile書式の整理、イメージの軽量化、ビルドツールの理解 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run Ship /

    イメージレジストリ イメージレジストリの紹介、イメージセキュリティとしてTrivyを理解 Run / コンテナ実行 コンテナの起動、停止、接続などDockerの基本コマンドを理解 永続化データとネットワークモデル 単体コンテナとしての永続化デートとネットワークモデルの整理と理解
  14. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run Build / イメージビルド Dockerfileの作成 $ docker image

    build イメージビルドコマンドの実行 Container Image イメージ生成 #ベースイメージのPull FROM centos:7 #epel-releaseインストール RUN yum -y install epel-release #nginxインストール RUN yum -y install nginx #index.htmlを/usr/share/nginx/index.htmlにコピー COPY index.html /usr/share/nginx/html #nginxのフォアグラウンド処理 ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;“] 「docker image build」コマンドでは、Dockerfileの上から 順番に処理が実行されます。 Dockerfile
  15. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run Dockerfile、ビルド、イメージの関係性 #ベースイメージのPull FROM centos:7 #epel-releaseインストール RUN yum

    -y install epel-release #nginxインストール RUN yum -y install nginx #index.htmlを/usr/share/nginx/index.htmlにコピー COPY index.html /usr/share/nginx/html #nginxのフォアグラウンド処理 ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;"] Dockerfile # docker image build -t cyberblack28/sample-nginx . Sending build context to Docker daemon 29.18kB Step 1/5 : FROM centos:7 ・ ・<省略> ・ ---> 7e6257c9f8d8 Step 2/5 : RUN yum -y install epel-release ---> Running in 1a6ea01a9382 ・ ・<省略> ・ ---> b58fcc402d22 Step 3/5 : RUN yum -y install nginx ---> Running in 9eacd9b3caa1 ・ ・<省略> ・ ---> cc0ba96f9da7 Step 4/5 : COPY index.html /usr/share/nginx/html ---> 481e53617e12 Step 5/5 : ENTRYPOINT [“nginx”, “-g”, “daemon off;”] ---> Running in 33a4c5304825 Removing intermediate container 33a4c5304825 ---> 124f75914199 Successfully built 124f75914199 Successfully tagged cyberblack28/sample-nginx:latest ビルド # docker image history cyberblack28/sample-nginx IMAGE CREATED CREATED BY SIZE COMMENT 124f75914199 10 minutes ago /bin/sh -c #(nop) ENTRYPOINT ["/bin/sh" "-c… 0B 481e53617e12 10 minutes ago /bin/sh -c #(nop) COPY file:764d0af30d8866d5… 130B cc0ba96f9da7 11 minutes ago /bin/sh -c yum -y install nginx 206MB b58fcc402d22 11 minutes ago /bin/sh -c yum -y install epel-release 91.7MB 7e6257c9f8d8 4 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B <missing> 4 weeks ago /bin/sh -c #(nop) LABEL org.label-schema.sc… 0B <missing> 4 weeks ago /bin/sh -c #(nop) ADD file:61908381d3142ffba… 203MB イメージ ① ② ③ ④ ⑤ ① ② ③ ④ ⑤ ① ② ③ ④ ⑤
  16. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run Dockerfileリファレンス 1.ADDとCOPY ファイル tar形式 ファイル ディレクトリ リモート

    ファイル ADD ファイル ディレクトリ COPY ローカルにあるファイルやディレクトリをビルドするイメージに含める命令として、ADD命令とCOPY命令がある • ローカルにあるファイル、ディレクトリ、tar形式ファイル、 リモートファイルを指定先(パス)に配置 • tar形式ファイルは自動展開される • ZIP形式ファイルは解凍されない • ローカルにあるファイル、ディレクトリを指定先(パス)に 配置 ビルド中、ファイルやディレクトリを配置する場合はCOPY命令を使用、リモートからのファイルおよびtarファイルを展開する場合は、 ADD命令を推奨
  17. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run 2. CMDとENTRYPOINT Dockerfileでコマンドを実行する命令としてCMD命令とENTRYPOINT命令があり、書式としてshellとexecの形式がある DockerfileでCMD命令とENTRYPOINT命令で指定した内容も、「$ docker container run」コマンドのオプション、引数を実

    行時に指定した場合、CMDとENTRYPOINTおよびshellとexec形式とで挙動が変わる(上書きされるされない) 項目 説明 CMD(shell形式 / exec形式) コンテナ起動時に変更可能なデフォルトコマンド 「$ docker container run」実行時の引数等で上書き可能 ENTRYPOINT(shell形式) コンテナ起動時に実行を必須とするコマンド 「$ docker container run」実行時の引数等で上書き不可、ただし「--entrypoint」オプションを指定すると上書き可能 ENTRYPOINT(exec形式) コンテナ起動時に実行を必須とするコマンド 「$ docker container run」実行時の引数等で上書き不可、ただしexec形式の場合は引数だけ追加可能、「--entrypoint」オプションを 指定すると上書き可能
  18. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run イメージの軽量化 イメージはレイヤ数が増えるほど容量が多くなり、サイズが増えると以下の弊害が生じる • イメージのビルド時間が増える • イメージレジストリへのアップロード(Push)時間が増える •

    イメージレジストリからのダウンロード(Pull)時間が増える • ホストでのディスク消費 軽量化のチューニング方法を取り入れて軽量化を図る • 軽量なベースイメージの利用 • 不要ファイルの削除 • 不要プログラムの削除 • 依存ライブラリの削除
  19. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run マルチステージビルド App Build イメージ ソースコード Build (Compile)

    ビルドライブラリ Execution イメージ 実行環境 Copy Execution イメージサイズ:Heavy イメージサイズ:Light One Dockerfile Build Stage1 Stage2 アーティファクト アーティファクト コンパイル用のイメージとコンパイルして生成された成果物を展開するイメージ、つまりアプリケーションビルド用と実行用のイメージを分けて、1つのDockerfileで 行う手法。必要なものはコンパイルされた成果物(バイナリファイル等)であり、コンパイラ等を含むビルド資材は、実行用のイメージには不要。実行用のイメージ には成果物を実行できる環境があればよいので、イメージの軽量化を実現。 #Stage1 #Goのビルドを実行するベースイメージを取得 FROM golang:1.16.4-alpine3.13 as builder #ローカルのmain.goをイメージ内にコピー COPY ./main.go ./ #main.goをソースからビルド(コンパイル)して、msbというビルド成果物を 生成 RUN go build -o /msb ./main.go #Stage2 #alpineのベースイメージを取得 FROM alpine:3.13 #ビルドイメージからビルド成果物のmsbをコピーして配置 COPY --from=builder /msb /usr/local/bin/msb #msbの実行 ENTRYPOINT ["/usr/local/bin/msb"]
  20. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run Ship / イメージレジストリ Image Registry 参考URL 種別

    Docker Hub https://hub.docker.com/ パブリックレジストリ Docker Trusted Registry (DTR) https://docs.mirantis.com/docker-enterprise/v3.0/dockeree-products/dtr.html プライベートレジストリ Red Hat Quay.io https://quay.io/ プライベートレジストリ Amazon Elastic Container Registry(ECR) https://aws.amazon.com/jp/ecr/ プライベートレジストリ Azure Container Registry(ACR) https://docs.microsoft.com/ja-jp/azure/container-registry/ プライベートレジストリ Google Container Registry(GCR) https://cloud.google.com/container-registry?hl=ja プライベートレジストリ Oracle Cloud Infrastructure Container Registry (OCIR) https://www.oracle.com/jp/cloud-native/container-registry/ パブリック/プライベートレジストリ Harbor https://goharbor.io/ パブリック/プライベートレジストリ GitHub Container Registry https://docs.github.com/ja/packages/getting-started-with-github-container- registry/about-github-container-registry パブリックレジストリ GitLab Container Registry https://docs.gitlab.com/ee/user/packages/container_registry/ パブリック/プライベートレジストリ 主なイメージレジストリ Docker Hubを利用して、イメージのPushとPullを実施
  21. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run Trivy コンテナイメージの脆弱性を静的に診断するツールで、OSパッケージ情報、アプリケーションの依存関係などから脆弱性を検出、 Aqua Security社がOSSとして公開している https://github.com/aquasecurity/trivy 主な特徴 •

    ワンバイナリでインストール、操作が簡単 • 脆弱性データベースから診断 • スキャンと結果出力が速い • コンテナイメージだけでなくローイカルファイルシステムやリモートgitリポジトリなどサポート
  22. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run Container Image 2022-03-03T07:19:27.161Z INFO Detected OS: debian

    2022-03-03T07:19:27.162Z INFO Detecting Debian vulnerabilities... 2022-03-03T07:19:27.167Z INFO Number of language-specific files: 1 icn.ocir.io/orasejapan/ochacafe5-3:arm (debian 11.2) ==================================================== Total: 4 (HIGH: 1, CRITICAL: 3) +---------+------------------+----------+-------------------+---------------+---------------------------------------+ | LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE | +---------+------------------+----------+-------------------+---------------+---------------------------------------+ | libc6 | CVE-2021-33574 | CRITICAL | 2.31-13+deb11u2 | | glibc: mq_notify does | | | | | | | not handle separately | | | | | | | allocated thread attributes | | | | | | | -->avd.aquasec.com/nvd/cve-2021-33574 | + +------------------+ + +---------------+---------------------------------------+ | | CVE-2022-23218 | | | | glibc: Stack-based buffer overflow | | | | | | | in svcunix_create via long pathnames | | | | | | | -->avd.aquasec.com/nvd/cve-2022-23218 | + +------------------+ + +---------------+---------------------------------------+ | | CVE-2022-23219 | | | | glibc: Stack-based buffer | | | | | | | overflow in sunrpc clnt_create | | | | | | | via a long pathname | | | | | | | -->avd.aquasec.com/nvd/cve-2022-23219 | + +------------------+----------+ +---------------+---------------------------------------+ | | CVE-2021-3999 | HIGH | | | glibc: Off-by-one buffer | | | | | | | overflow/underflow in getcwd() | | | | | | | -->avd.aquasec.com/nvd/cve-2021-3999 | +---------+------------------+----------+-------------------+---------------+---------------------------------------+ $ trivy image --severity HIGH,CRITICAL イメージ名
  23. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run 永続化データとネットワークモデル Dockerにおける、コンテナホストとコンテナとの間でデータを共有する3つのマウント形式の説明と実装 コンテナホスト Container ファイルシステム Dockerエリア メモリー

    一時ファイルシステム のマウント バインドマウント ボリューム バインドマウント (bind mount) コンテナホストのファイル・ディレクトリをコンテナ上でマウント ボリューム (volume) Dockerが管理するデータ領域をコンテナ上にマウント 一時ファイルシステムのマウント (tmpfs mount) コンテナホストに保存したくないデータを一時的にデータ領域のメ モリ上に保存 1.永続化データ
  24. 第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run Dockerをベースにコンテナのネットワークモデル(none/host/bridge)の説明と実装 コンテナホスト Container none • コンテナにネットワーク・インターフェイスを持たせないモデル •

    コンテナの内外通信が不可 2.ネットワークモデル eth0 コンテナホスト Container host • コンテナがコンテナホストのネットワーク・インターフェイスを共 有するモデル • コンテナホストと同じネットワーク・インターフェイスとIPを持つ eth0
  25. 4章のポイント Kubernetesの概要 Kubernetesが登場した経緯、実現するコンテナオーケストレーションの役割を分散処理としての捉え方を説明 第4章 コンテナオーケストレーション クラウドネイティブへの取り組み 2019年「KubeCon + CloudNativeCon North

    America 2019」で発表された事例を軸にクラウドネイティブの取り組み紹介 Kubernetesアーキテクチャ Kubernetesクラスタを構成するControl PlaneとNodeの詳解 Kubernetesのリソース 基本となるKubernetesのリソースとラベルやkubectlコマンドの説明 Kubernetesクラスタの構築 Kubernetesクラスタ構築のセットアップ手順
  26. 第4章 コンテナオーケストレーション Kubernetesの主な役割と実現 • コンテナのスケジューリング • ローリングアップデート • オートスケーリング •

    死活監視 • 頻繁なアプリケーションのデプロイを可能にするシステム基盤 • 無停止によるリリース、高可用なシステム基盤 • 負荷に応じた伸縮自在なシステム基盤 主な役割 実現 • コンテナの自動修復 • サービスディスカバリ • ロードバランシング
  27. 第4章 コンテナオーケストレーション Kubernetesのリソース • Podの概要 • コンテナランタイム • デザインパターン サイドカー

    アンバサダー アダプター Pod • ReplicaSetの概要 • Deploymentの概要 ReplicaSet & Deployment • Serviceの概要 • サービスタイプ ClusterIP NodePort LoadBalancer Service • Ingressの概要 Ingress • PersistentVolume & PersistentVolumeClaimの概要 PersistentVolume & PersistentVolumeClaim • ConfigMapの概要 • Secretの概要 ConfigMap & Secret • Labelの概要 Label • Namespaceの概要 Namespace • kubectlの概要 kubectl • Reclaim Policy Delete Retain Recycle • Storage Class • アクセスモード RWO ROX RWX この章で、Kubernetesの基本となるリソースの概要を掴んで、次章で実 際にセットアップしたKubernetesクラスタ上でオブジェクトとして作成します
  28. 5章のポイント kubectlコマンド Pod、Deployment、Service、ConfigMap、Secret、Multi Container Podなど前章で概要を学んだリソースをマニフェストか ら登録、kubectlコマンドにおけるcreateとapplyの整理 第5章 Kubernetesでコンテナアプリケーションを動かすまで Kubernetesでアプリケーションを動かす NFSを作成して、実際にPersistentVolume/PersistentVolumeClaimを利用したWordPress環境の構築、WordPress

    Podのスケールアウト/イン、アプリケーションの削除 マニフェストファイルの管理 WordPress環境構築に利用した複数のマニフェストを、Helmを利用してテンプレートに置き換えてマニフェストの効率化を体感、 OSSとして公開されているWordPressのHelm Chartを利用したデプロイを実践
  29. 第5章 Kubernetesでコンテナアプリケーションを動かすまで Kubernetesでアプリケーションを動かす WordPress環境の構築(独自Helm Chart) 「$kubectl delete」コ マンドと 「$helm uninstall」

    コマンドで のアプリ ケーション 削除の違い を確認 マニフェストとHelm Chartにおけるマニフェス ト管理の効率化を確認
  30. ローカル開発環境の種別 第6章 ローカル開発の準備 Authors: Michael Hausenblas (Red Hat), Ilya Dmitrichenko

    (Weaveworks) (Tuesday, May 01, 2018) Developing on Kubernetes,Kubernetes Blog. オフラインタイプ(pure off-line) プロキシタイプ(proxied) ライブタイプ(live) オンラインタイプ(pure on-line) ローカルの開発マシン(ラップトップまたはデスクトッ プ)内で完結 アプリケーション作成やイメージのビルドはローカル開発環 境、Kubernetesクラスタはリモート実装 開発もKubernetesクラスタもすべてリモート
  31. Skaffoldを利用したローカル開発実践 第6章 ローカル開発の準備 Dockerfile Sample Application Surce Code Yaml (Deployment/Service)

    skaffold.yaml Docker Hub Yaml (Deployment/Service/values) Helm apiVersion: skaffold/v2beta10 kind: Config build: artifacts: - image: docker.io/DOCKERHUB_REPO_NAME/practice-skaffold # 変更箇所 DOCKERHUB_REPO_NAME docker: dockerfile: ./Dockerfile tagPolicy: dateTime: {} local: push: true deploy: helm: releases: - name: practice-skaffold chartPath: skaffold-helm valuesFiles: [ skaffold-helm/values.yaml ] artifactOverrides: image: docker.io/DOCKERHUB_REPO_NAME/practice-skaffold # 変更箇所 DOCKERHUB_REPO_NAME apiVersion: skaffold/v2alpha3 kind: Config build: artifacts: - image: DOCKERHUB_REPO_NAME/practice-skaffold # 変更箇所 DOCKERHUB_REPO_NAME docker: dockerfile: ./Dockerfile tagPolicy: dateTime: {} local: push: true deploy: kubectl: manifests: - practice-skaffold-* Helm & Skaffold $ skaffold dev -f skaffold.yaml Build Ship Run
  32. <詳細・お申し込み> http://oracle.com/goto/emp-oradev Developer Days 未来を創造する最新テクノロジーを今、あなたの手に。 ITに携わるすべての開発者とエンジニアに オラクル テクノロジー最新情報を お届けするオンラインイベントを2日間開催! ❃━━━…‥・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    DB Day : 2022年5月20日 (金) 13:00 ~ Cloud Day : 2022年5月27日 (金) 13:00 ~ オンライン開催 参加費:無料 (事前登録制) ハッシュタグ: #oradev22 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・‥…━━━❃