著者は、Write for DOnationsプログラムの一部として寄付を受け取るためにFree and Open Source Fundを選択しました。
前書き
Kubernetesは、コンテナを大規模に管理するコンテナオーケストレーションシステムです。 Kubernetesは、運用環境でコンテナを実行した経験に基づいてGoogleが最初に開発したオープンソースであり、世界中のコミュニティによって積極的に開発されています。
[.note]#Note:このチュートリアルでは、この記事の公開時点でサポートされている公式バージョンであるバージョン1.14のKubernetesを使用しています。 最新バージョンの最新情報については、Kubernetesの公式ドキュメントのcurrent release notesを参照してください。
#
Kubeadmは、APIサーバー、コントローラーマネージャー、KubeDNSなどのKubernetesコンポーネントのインストールと構成を自動化します。 ただし、ユーザーの作成や、オペレーティングシステムレベルの依存関係とその構成のインストールは処理しません。 これらの予備タスクでは、AnsibleやSaltStackなどの構成管理ツールを使用できます。 これらのツールを使用すると、追加のクラスターを作成したり、既存のクラスターを再作成したりするのがはるかに簡単になり、エラーが発生しにくくなります。
このガイドでは、AnsibleとKubeadmを使用してゼロからKubernetesクラスターをセットアップし、コンテナー化されたNginxアプリケーションをデプロイします。
目標
クラスターには、次の物理リソースが含まれます。
-
1つのマスターノード
マスターノード(Kubernetesのnodeはサーバーを指します)は、クラスターの状態を管理する役割を果たします。 Etcdを実行し、ワークロードをワーカーノードにスケジュールするコンポーネント間でクラスターデータを格納します。
-
2つのワーカーノード
ワーカーノードは、workloadsが存在するサーバーです(つまり、 コンテナ化されたアプリケーションとサービス)が実行されます。 ワーカーは、スケジューリングが完了するとマスターがダウンしても、割り当てられたワークロードを引き続き実行します。 ワーカーを追加すると、クラスターの容量を増やすことができます。
このガイドを完了すると、クラスター内のサーバーにアプリケーションが消費するのに十分なCPUリソースとRAMリソースがあれば、コンテナー化されたアプリケーションを実行する準備が整います。 Webアプリケーション、データベース、デーモン、およびコマンドラインツールを含む、ほぼすべての従来のUnixアプリケーションをコンテナ化して、クラスター上で実行することができます。 クラスター自体は、各ノードで約300〜500MBのメモリと10%のCPUを消費します。
クラスターをセットアップしたら、WebサーバーNginxをクラスターにデプロイして、ワークロードが正しく実行されていることを確認します。
前提条件
-
ローカルLinux / macOS / BSDマシン上のSSHキーペア。 これまでSSHキーを使用したことがない場合は、このhow to set up SSH keys on your local machineの説明に従って、SSHキーを設定する方法を学ぶことができます。
-
2 GB以上のRAMとそれぞれ2つのvCPUを備えたCentOS 7を実行する3つのサーバー。 SSHキーペアを使用して、rootユーザーとして各サーバーにSSH接続できるはずです。 マスターノードのcentosユーザーのアカウントにも公開鍵を追加してください。 特定のユーザーアカウントにSSHキーを追加するためのガイダンスが必要な場合は、How To Set Up SSH Keys on CentOS7に関するこのチュートリアルを参照してください。
-
ローカルマシンにインストールされたAnsible。 インストール手順については、official Ansible installation documentationに従ってください。
-
Ansibleプレイブックに精通している。 レビューについては、Configuration Management 101: Writing Ansible Playbooksを確認してください。
-
Dockerイメージからコンテナーを起動する方法に関する知識。 復習が必要な場合は、How To Install and Use Docker on CentOS 7の「ステップ5 — Dockerコンテナーの実行」を参照してください。
[[step-1 -—- setting-up-the-workspace-directory-and-ansible-inventory-file]] ==ステップ1—ワークスペースディレクトリとAnsibleインベントリファイルの設定
このセクションでは、ローカルマシン上にワークスペースとして機能するディレクトリを作成します。 また、リモートサーバーと通信してコマンドを実行できるように、Ansibleをローカルで構成します。 これを行うには、サーバーのIPアドレスや各サーバーが属するグループなどのインベントリ情報を含むhosts
ファイルを作成します。
3つのサーバーのうち、1つはIPがmaster_ip
として表示されるマスターになります。 他の2つのサーバーはワーカーであり、IPはworker_1_ip
とworker_2_ip
になります。
ローカルマシンのホームディレクトリに~/kube-cluster
という名前のディレクトリを作成し、その中にcd
を作成します。
mkdir ~/kube-cluster
cd ~/kube-cluster
このディレクトリは、残りのチュートリアルのワークスペースであり、すべてのAnsibleプレイブックが含まれます。 また、すべてのローカルコマンドを実行するディレクトリです。
vi
またはお気に入りのテキストエディタを使用して、~/kube-cluster/hosts
という名前のファイルを作成します。
vi ~/kube-cluster/hosts
i
を押して、次のテキストをファイルに挿入します。これにより、クラスターの論理構造に関する情報が指定されます。
~/kube-cluster/hosts
[masters]
master ansible_host=master_ip ansible_user=root
[workers]
worker1 ansible_host=worker_1_ip ansible_user=root
worker2 ansible_host=worker_2_ip ansible_user=root
終了したら、ESC
を押してから:wq
を押してファイルに変更を書き込み、終了します。
Ansibleのinventory filesは、IPアドレス、リモートユーザー、コマンドを実行するための単一のユニットとしてターゲットとするサーバーのグループなどのサーバー情報を指定するために使用されることを思い出してください。 ~/kube-cluster/hosts
がインベントリファイルになり、クラスターの論理構造を指定する2つのAnsibleグループ(mastersとworkers)を追加しました。
mastersグループには、マスターノードのIP(master_ip
)を一覧表示し、Ansibleがrootユーザーとしてリモートコマンドを実行するように指定する「master」という名前のサーバーエントリがあります。
同様に、workersグループには、ワーカーサーバー用の2つのエントリ(worker_1_ip
とworker_2_ip
)があり、これらもansible_user
をrootとして指定します。
グループでサーバーインベントリを設定したら、オペレーティングシステムレベルの依存関係のインストールと構成設定の作成に移りましょう。
[[step-2 -—- installing-kubernetes-39-dependencies]] ==ステップ2—Kubernetesの依存関係をインストールする
このセクションでは、CentOSのyum
パッケージマネージャーを使用して、Kubernetesに必要なオペレーティングシステムレベルのパッケージをインストールします。 これらのパッケージは次のとおりです。
-
Docker-コンテナーランタイム。 これは、コンテナを実行するコンポーネントです。 rktなどの他のランタイムのサポートは、Kubernetesで活発に開発されています。
-
kubeadm
-クラスターのさまざまなコンポーネントを標準的な方法でインストールおよび構成するCLIツール。 -
kubelet
-すべてのノードで実行され、ノードレベルの操作を処理するシステムサービス/プログラム。 -
kubectl
-APIサーバーを介してクラスターにコマンドを発行するために使用されるCLIツール。
ワークスペースに~/kube-cluster/kube-dependencies.yml
という名前のファイルを作成します。
vi ~/kube-cluster/kube-dependencies.yml
次の再生をファイルに追加して、これらのパッケージをサーバーにインストールします。
~/kube-cluster/kube-dependencies.yml
- hosts: all
become: yes
tasks:
- name: install Docker
yum:
name: docker
state: present
update_cache: true
- name: start Docker
service:
name: docker
state: started
- name: disable SELinux
command: setenforce 0
- name: disable SELinux on reboot
selinux:
state: disabled
- name: ensure net.bridge.bridge-nf-call-ip6tables is set to 1
sysctl:
name: net.bridge.bridge-nf-call-ip6tables
value: 1
state: present
- name: ensure net.bridge.bridge-nf-call-iptables is set to 1
sysctl:
name: net.bridge.bridge-nf-call-iptables
value: 1
state: present
- name: add Kubernetes' YUM repository
yum_repository:
name: Kubernetes
description: Kubernetes YUM repository
baseurl: https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
gpgkey: https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
gpgcheck: yes
- name: install kubelet
yum:
name: kubelet-1.14.0
state: present
update_cache: true
- name: install kubeadm
yum:
name: kubeadm-1.14.0
state: present
- name: start kubelet
service:
name: kubelet
enabled: yes
state: started
- hosts: master
become: yes
tasks:
- name: install kubectl
yum:
name: kubectl-1.14.0
state: present
allow_downgrade: yes
プレイブックの最初のプレイは次のことを行います。
-
コンテナランタイムであるDockerをインストールします。
-
Dockerサービスを開始します。
-
Kubernetesによってまだ完全にサポートされていないため、SELinuxを無効にします。
-
ネットワークに必要ないくつかのnetfilter関連の
sysctl
値を設定します。 これにより、Kubernetesは、ノードでブリッジされたIPv4およびIPv6ネットワークトラフィックを受信するためのiptablesルールを設定できます。 -
Kubernetes YUMリポジトリをリモートサーバーのリポジトリリストに追加します。
-
kubelet
およびkubeadm
をインストールします。
2番目のプレイは、マスターノードにkubectl
をインストールする単一のタスクで構成されます。
[.note]#Note: Kubernetesのドキュメントでは、ご使用の環境に最新の安定版Kubernetesを使用することを推奨していますが、このチュートリアルでは特定のバージョンを使用しています。 これにより、Kubernetesは急速に変化し、最新バージョンがこのチュートリアルで機能しない可能性があるため、手順を正常に実行できるようになります。
#
完了したら、ファイルを保存して閉じます。
次に、プレイブックを実行します。
ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml
完了すると、次のような出力が表示されます。
OutputPLAY [all] ****
TASK [Gathering Facts] ****
ok: [worker1]
ok: [worker2]
ok: [master]
TASK [install Docker] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [disable SELinux] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [disable SELinux on reboot] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [ensure net.bridge.bridge-nf-call-ip6tables is set to 1] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [ensure net.bridge.bridge-nf-call-iptables is set to 1] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [start Docker] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [add Kubernetes' YUM repository] *****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [install kubelet] *****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [install kubeadm] *****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [start kubelet] ****
changed: [master]
changed: [worker1]
changed: [worker2]
PLAY [master] *****
TASK [Gathering Facts] *****
ok: [master]
TASK [install kubectl] ******
ok: [master]
PLAY RECAP ****
master : ok=9 changed=5 unreachable=0 failed=0
worker1 : ok=7 changed=5 unreachable=0 failed=0
worker2 : ok=7 changed=5 unreachable=0 failed=0
実行後、Docker、kubeadm
、およびkubelet
がすべてのリモートサーバーにインストールされます。 kubectl
は必須コンポーネントではなく、クラスターコマンドの実行にのみ必要です。 マスターからのみkubectl
コマンドを実行するため、このコンテキストではマスターノードにのみインストールするのが理にかなっています。 ただし、kubectl
コマンドは、任意のワーカーノードから、またはクラスターを指すようにインストールおよび構成できる任意のマシンから実行できることに注意してください。
これで、すべてのシステム依存関係がインストールされました。 マスターノードをセットアップして、クラスターを初期化しましょう。
[[step-4 -—- setting-up-the-master-node]] ==ステップ4—マスターノードのセットアップ
このセクションでは、マスターノードを設定します。 ただし、クラスタには両方が含まれるため、プレイブックを作成する前に、PodsやPod Network Pluginsなどのいくつかの概念を説明する価値があります。
ポッドは、1つ以上のコンテナーを実行するアトミックユニットです。 これらのコンテナは、ファイルボリュームやネットワークインターフェイスなどのリソースを共有します。 ポッドはKubernetesのスケジューリングの基本単位です。ポッド内のすべてのコンテナーは、ポッドがスケジュールされている同じノードで実行されることが保証されています。
各ポッドには独自のIPアドレスがあり、1つのノード上のポッドは、ポッドのIPを使用して別のノード上のポッドにアクセスできる必要があります。 単一ノード上のコンテナは、ローカルインターフェイスを介して簡単に通信できます。 ただし、ポッド間の通信はより複雑であり、1つのノードのポッドから別のノードのポッドにトラフィックを透過的にルーティングできる個別のネットワークコンポーネントが必要です。
この機能は、ポッドネットワークプラグインによって提供されます。 このクラスターでは、安定したパフォーマンスの高いオプションであるFlannelを使用します。
ローカルマシンでmaster.yml
という名前のAnsibleプレイブックを作成します。
vi ~/kube-cluster/master.yml
次の再生をファイルに追加して、クラスターを初期化し、Flannelをインストールします。
~/kube-cluster/master.yml
- hosts: master
become: yes
tasks:
- name: initialize the cluster
shell: kubeadm init --pod-network-cidr=10.244.0.0/16 >> cluster_initialized.txt
args:
chdir: $HOME
creates: cluster_initialized.txt
- name: create .kube directory
become: yes
become_user: centos
file:
path: $HOME/.kube
state: directory
mode: 0755
- name: copy admin.conf to user's kube config
copy:
src: /etc/kubernetes/admin.conf
dest: /home/centos/.kube/config
remote_src: yes
owner: centos
- name: install Pod network
become: yes
become_user: centos
shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml >> pod_network_setup.txt
args:
chdir: $HOME
creates: pod_network_setup.txt
このプレイの内訳は次のとおりです。
-
最初のタスクは、
kubeadm init
を実行してクラスターを初期化します。 引数--pod-network-cidr=10.244.0.0/16
を渡すと、ポッドIPの割り当て元となるプライベートサブネットが指定されます。 Flannelはデフォルトで上記のサブネットを使用します。kubeadm
に同じサブネットを使用するように指示しています。 -
2番目のタスクは、
/home/centos
に.kube
ディレクトリを作成します。 このディレクトリには、クラスターへの接続に必要な管理キーファイルやクラスターのAPIアドレスなどの構成情報が保持されます。 -
3番目のタスクは、
kubeadm init
から生成された/etc/kubernetes/admin.conf
ファイルをルート以外のcentosユーザーのホームディレクトリにコピーします。 これにより、kubectl
を使用して新しく作成されたクラスターにアクセスできます。 -
最後のタスクは
kubectl apply
を実行してFlannel
をインストールします。kubectl apply -f descriptor.[yml|json]
は、descriptor.[yml|json]
ファイルに記述されているオブジェクトを作成するようにkubectl
に指示するための構文です。kube-flannel.yml
ファイルには、クラスターでFlannel
をセットアップするために必要なオブジェクトの説明が含まれています。
完了したら、ファイルを保存して閉じます。
プレイブックを実行します。
ansible-playbook -i hosts ~/kube-cluster/master.yml
完了すると、次のような出力が表示されます。
Output
PLAY [master] ****
TASK [Gathering Facts] ****
ok: [master]
TASK [initialize the cluster] ****
changed: [master]
TASK [create .kube directory] ****
changed: [master]
TASK [copy admin.conf to user's kube config] *****
changed: [master]
TASK [install Pod network] *****
changed: [master]
PLAY RECAP ****
master : ok=5 changed=4 unreachable=0 failed=0
マスターノードのステータスを確認するには、次のコマンドを使用してSSHでマスターノードに接続します。
ssh centos@master_ip
マスターノード内で、次を実行します。
kubectl get nodes
次の出力が表示されます。
OutputNAME STATUS ROLES AGE VERSION
master Ready master 1d v1.14.0
出力には、master
ノードがすべての初期化タスクを完了し、Ready
状態にあり、そこからワーカーノードの受け入れとAPIサーバーに送信されたタスクの実行を開始できることが示されます。 これで、ローカルマシンからワーカーを追加できます。
[[step-5 -—- setting-up-the-worker-nodes]] ==ステップ5—ワーカーノードの設定
クラスターにワーカーを追加するには、それぞれに対して単一のコマンドを実行する必要があります。 このコマンドには、マスターのAPIサーバーのIPアドレスとポート、セキュアトークンなどの必要なクラスター情報が含まれます。 セキュアトークンを渡すノードのみがクラスターに参加できます。
ワークスペースに戻り、workers.yml
という名前のプレイブックを作成します。
vi ~/kube-cluster/workers.yml
次のテキストをファイルに追加して、ワーカーをクラスターに追加します。
~/kube-cluster/workers.yml
- hosts: master
become: yes
gather_facts: false
tasks:
- name: get join command
shell: kubeadm token create --print-join-command
register: join_command_raw
- name: set join command
set_fact:
join_command: "{{ join_command_raw.stdout_lines[0] }}"
- hosts: workers
become: yes
tasks:
- name: join cluster
shell: "{{ hostvars['master'].join_command }} --ignore-preflight-errors all >> node_joined.txt"
args:
chdir: $HOME
creates: node_joined.txt
プレイブックの機能は次のとおりです。
-
最初のプレイでは、ワーカーノードで実行する必要があるjoinコマンドを取得します。 このコマンドの形式は次のとおりです。`kubeadmjoin--token
: --discovery-token-ca-cert-hash sha256: `。 適切なtokenとhashの値を持つ実際のコマンドを取得すると、タスクはそれをファクトとして設定し、次のプレイがその情報にアクセスできるようにします。 -
2番目のプレイには、すべてのワーカーノードでjoinコマンドを実行する単一のタスクがあります。 このタスクが完了すると、2つのワーカーノードがクラスターの一部になります。
完了したら、ファイルを保存して閉じます。
プレイブックを実行します。
ansible-playbook -i hosts ~/kube-cluster/workers.yml
完了すると、次のような出力が表示されます。
OutputPLAY [master] ****
TASK [get join command] ****
changed: [master]
TASK [set join command] *****
ok: [master]
PLAY [workers] *****
TASK [Gathering Facts] *****
ok: [worker1]
ok: [worker2]
TASK [join cluster] *****
changed: [worker1]
changed: [worker2]
PLAY RECAP *****
master : ok=2 changed=1 unreachable=0 failed=0
worker1 : ok=2 changed=1 unreachable=0 failed=0
worker2 : ok=2 changed=1 unreachable=0 failed=0
ワーカーノードを追加すると、クラスターが完全にセットアップされて機能するようになり、ワーカーはワークロードを実行する準備が整います。 アプリケーションをスケジュールする前に、クラスターが意図したとおりに機能していることを確認しましょう。
[[step-6 -—- verifying-the-cluster]] ==ステップ6—クラスターの検証
ノードがダウンしているか、マスターとワーカー間のネットワーク接続が正しく機能していないため、セットアップ中にクラスターが失敗することがあります。 クラスターを検証し、ノードが正しく動作していることを確認しましょう。
マスターノードからクラスターの現在の状態をチェックして、ノードの準備ができていることを確認する必要があります。 マスターノードから切断した場合、次のコマンドを使用してSSHでマスターノードに戻すことができます。
ssh centos@master_ip
次に、次のコマンドを実行して、クラスターのステータスを取得します。
kubectl get nodes
次のような出力が表示されます。
OutputNAME STATUS ROLES AGE VERSION
master Ready master 1d v1.14.0
worker1 Ready 1d v1.14.0
worker2 Ready 1d v1.14.0
すべてのノードのSTATUS
の値がReady
である場合、それらはクラスターの一部であり、ワークロードを実行する準備ができていることを意味します。
ただし、一部のノードのSTATUS
がNotReady
である場合は、ワーカーノードがまだセットアップを完了していない可能性があります。 kubectl get node
を再実行し、新しい出力を検査する前に、約5〜10分待ちます。 いくつかのノードのステータスがまだNotReady
である場合は、前の手順でコマンドを確認して再実行する必要がある場合があります。
クラスターが正常に検証されたので、クラスターでサンプルのNginxアプリケーションをスケジュールしましょう。
[[step-7 -—- running-an-application-on-the-cluster]] ==ステップ7—クラスターでのアプリケーションの実行
これで、コンテナ化されたアプリケーションをクラスターにデプロイできます。 慣れるために、DeploymentsとServicesを使用してNginxをデプロイし、このアプリケーションをクラスターにデプロイする方法を確認しましょう。 Dockerイメージ名と関連するフラグ(ports
やvolumes
など)を変更すれば、他のコンテナー化されたアプリケーションにも以下のコマンドを使用できます。
マスターノード内で、次のコマンドを実行して、nginx
という名前のデプロイメントを作成します。
kubectl create deployment nginx --image=nginx
デプロイメントはKubernetesオブジェクトの一種で、クラスターの存続期間中にポッドがクラッシュした場合でも、定義されたテンプレートに基づいて、指定された数のポッドが常に実行されるようにします。 上記のデプロイでは、DockerレジストリのNginx Docker Imageから1つのコンテナを含むポッドが作成されます。
次に、次のコマンドを実行して、アプリを公開するnginx
という名前のサービスを作成します。 これは、NodePortを介して行われます。これは、クラスターの各ノードで開かれている任意のポートを介してポッドにアクセスできるようにするスキームです。
kubectl expose deploy nginx --port 80 --target-port 80 --type NodePort
サービスは、クラスター内部サービスを内部および外部の両方のクライアントに公開する別の種類のKubernetesオブジェクトです。 また、複数のポッドへのリクエストの負荷分散が可能で、Kubernetesの不可欠なコンポーネントであり、他のコンポーネントと頻繁にやり取りします。
次のコマンドを実行してください。
kubectl get services
これにより、次のようなテキストが出力されます。
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP 1d
nginx NodePort 10.109.228.209 80:nginx_port/TCP 40m
上記の出力の3行目から、Nginxが実行されているポートを取得できます。 Kubernetesは、30000
より大きいランダムなポートを自動的に割り当てますが、ポートが別のサービスによってバインドされていないことを確認します。
すべてが機能していることをテストするには、ローカルマシンのブラウザからhttp://worker_1_ip:nginx_port
またはhttp://worker_2_ip:nginx_port
にアクセスします。 Nginxの使い慣れたウェルカムページが表示されます。
Nginxアプリケーションを削除する場合は、最初にマスターノードからnginx
サービスを削除します。
kubectl delete service nginx
次を実行して、サービスが削除されたことを確認します。
kubectl get services
次の出力が表示されます。
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP 1d
次に、デプロイメントを削除します。
kubectl delete deployment nginx
以下を実行して、これが機能したことを確認します。
kubectl get deployments
OutputNo resources found.
結論
このガイドでは、KubeadmとAnsible for automationを使用して、CentOS 7でKubernetesクラスターを正常にセットアップしました。
クラスターがセットアップされたので、クラスターで何をすべきか疑問に思っている場合は、次のステップとして、クラスターに独自のアプリケーションとサービスを快適にデプロイすることです。 プロセスのガイドとなる詳細情報を含むリンクのリストを次に示します。
-
Dockerizing applications-Dockerを使用してアプリケーションをコンテナー化する方法を詳しく説明する例を示します。
-
Pod Overview-ポッドがどのように機能し、他のKubernetesオブジェクトとの関係を詳細に説明します。 ポッドはKubernetesに遍在しているため、それらを理解すると作業が容易になります。
-
Deployments Overview-これは展開の概要を提供します。 デプロイメントなどのコントローラーは、スケーリングや不健全なアプリケーションの自動ヒーリングのためにステートレスアプリケーションで頻繁に使用されるため、どのように機能するかを理解しておくと役立ちます。
-
Services Overview-これは、Kubernetesクラスターで頻繁に使用されるもう1つのオブジェクトであるサービスを対象としています。 ステートレスアプリケーションとステートフルアプリケーションの両方を実行するには、サービスのタイプとそのオプションを理解することが不可欠です。
Kubernetesには、提供する多くの機能と機能があります。 The Kubernetes Official Documentationは、概念について学び、タスク固有のガイドを見つけ、さまざまなオブジェクトのAPIリファレンスを検索するのに最適な場所です。