Binary file paper/mk-wm.pdf has changed

--- a/paper/mk-wm.tex	Thu Aug 06 16:48:01 2020 +0900
+++ b/paper/mk-wm.tex	Thu Aug 06 18:30:46 2020 +0900
@@ -154,7 +154,7 @@
 GitLab Runner とは, ビルドのためのアプリケーションであり, GitLab CI と連携することで別の場所でビルドを動かすことができる。
 
 \section{本コースの類似サービス}
-本サービスに類似したサービスとして, libvirt の CLI である virsh をラップしマルチユーザ VM 環境を提供する ie-virsh 。
+本サービスに類似したサービスとして, libvirt の CLI である virsh をラップしマルチユーザ VM 環境を提供する ie-virsh \cite{ie-virsh} 。
 また, Docker をラップし複数のユーザで利用することを目的とした ie-docker , Kubernetes を利用した教育用コンテナ貸出を目的とした, digdog \cite{digdog} がある。
 
 \subsection{ie-virsh}
@@ -206,7 +206,8 @@
 学生は Dockerfile を GitLab CI/CD を利用して GitLab Registry に Docker イメージを登録する。
 学科アカウントを使用して Web サービスへログインし, 登録した Docker イメージでコンテナを作成することができる。
 コンテナ作成時は digdog が Kubernetes に Deployment を設定する。Deployment は学生のアカウント名で作成された Namespace に設定される。
-Namespace は RBAC を用いたリソース操作のアクセス制御が設定されている。そのため学生は Kubernetes コマンドである kubectl コマンドで 手元の PC から Pod の操作を行うことができる。 
+Namespace は Role と RoleBinding を用いた, Role-based access control (RBAC) が設定されている。
+そのため学生は Kubernetes コマンドである kubectl コマンドで 手元の PC から Pod の操作を行うことができる。 
 RBAC で許可されているリソース操作は表\ref{tb:digdog}である。
 
 \begin{table}[htb]
@@ -223,20 +224,14 @@
 
 
 \section{サービスの設計}
-学生が学習環境を利用する流れを図\ref{fig:wm} に示し, 概要を以下で説明する。
-
-\subsection{利用技術}
-サービスではコンテナ貸出を行う。
-そこで, コンテナ管理ソフトウェアである Docker, コンテナオーケストレーションソフトである Kubernetes, マルチユーザ環境に適した Linux コンテナである Singularity を利用する。\par
-サービスは Docker や Kubernetes のみで提供することもできる。だが, コンテナ内のデータの永続化が問題となる。そのため Singularity を利用する。
-Singularity では デフォルトで \$HOME, /tmp, /proc, /sys, /dev がコンテナにマウントされる。そのため, コンテナのデータの永続化や大量のデータを扱う場合に適している。
+サービスでは本コースの学生や教員がにコンテナ貸出を行う。このコンテナ貸出の構成を図\ref{fig:wm} に示し, 概要を以下で説明する。
 
 \subsection{コンテナの作成}
-学生は学科アカウントで Web コンソールへログインする。Web コンソールでは 学生のコンテナ一覧や Docker イメージ一覧を確認することができる。
-コンテナ作成を選択するとコンテナを作成するために必要な情報を入力する。入力する内容は表\ref{tb:wmcon} である。コンテナ名には学生のアカウント名が補完されるため, 他の学生と被ることはない。
-Docker イメージは Docker Hub に登録されているイメージや, 作成したイメージを入力することができる。環境変数とゲストポートはスペース区切りで複数入力することができる。
-ホストポートは, エフェメラルポート の範囲から設定される。学生は設定されたホストポートを使用してコンテナのサービスへアクセスする。
-また, 学生はコンテナに対して Web コンソールから, または手元の PC から操作することができる。
+学生または教員は学科アカウントで Web コンソールへログインする。Web コンソールでは ユーザのコンテナ一覧や Docker イメージ一覧を確認することができる。
+コンテナ作成を選択するとコンテナを作成するために必要な情報を入力する。入力する内容は表\ref{tb:wmcon} である。コンテナ名にはユーザのアカウント名が補完されるため, 他のユーザと被ることはない。
+Docker イメージには Docker Hub に登録されているイメージや, ユーザが作成したイメージを入力することができる。環境変数とゲストポートはスペース区切りで複数入力することができる。
+ホストポートは, エフェメラルポートの範囲から設定される。ユーザは設定されたホストポートを使用してコンテナのサービスへアクセスする。
+また, ユーザはコンテナに対して Web コンソールから, または手元の PC から操作することができる。
 必要なくなったコンテナは Web コンソールのコンテナ一覧から削除することができる。
 
 \begin{table}[htb]
@@ -253,18 +248,19 @@
 \end{table}
 
 \subsection{イメージの作成}
-Docker イメージの作成は学科で利用している GitLab の CI/CD 機能を使用する。
-学生は学科 GitLab から CI/CD トークンを取得し, Web コンソールで取得したトークンをセットする。この時 Docker 側に GitLab Runner \cite{gitlabrunner} の立ち上げを依頼する。
-トークンの設定後, Web コンソールから CI/CD 用の Yaml ファイルをダウンロードし Dockerfile と一緒に学科 GitLab のリポジトリに Push する。
-Docker イメージの Build が成功すると Web コンソールのイメージ一覧で確認ができる。作成した Docker イメージは編集からイメージの使い方を記述でき, 他の学生に共有するか設定を行える。
+Docker イメージの作成は学科で使用している GitLab の CI/CD の CI 機能を利用する。
+ユーザは学科 GitLab から CI トークンを取得し, Web コンソールで取得したトークンをセットする。この時 Docker 側に GitLab Runner の立ち上げを依頼する。
+トークンの設定後, Web コンソールから CI 用の YAML ファイルをダウンロードし Dockerfile と一緒に学科 GitLab のリポジトリにプッシュする。
+Docker イメージのビルドが成功すると Web コンソールのイメージ一覧で確認ができる。作成した Docker イメージは編集からイメージの使い方の記述や他の学生に共有するか設定を行える。
 必要なくなったイメージは Web コンソールのイメージ一覧から削除することができる。
 
 \subsection{Singularity の利用}
-Singularity は Docker イメージをSingularity 用に Build することで, Docker イメージを使用することができる。
-だが, イメージの Build には sudo 権限が必要となる。Docker イメージの Build を申請性にすると, 管理者の仕事が増え, 学生も利用しづらい。
-また, Singularity はユーザ権限で動作するため, 学生が ssh でブレードサーバへ接続し利用する方が適している。
+コンテナに大量のデータを送信する必要がある場合や, データを永続化させたい場合に Singularity を利用する。
+Singularity は Docker イメージを変換し使用できるが, イメージの変換には sudo 権限が必要となる。
+Docker イメージの変換を申請性にすると, 管理者の仕事が増え, またユーザも利用しづらい。
+Singularity はユーザ権限で動作することから, 学生が ssh でブレードサーバへ接続し利用する方が適している。
 そこで, Web コンソールから Singularity 用のイメージをダウンロードできる仕様とする。\par
-学生は利用したいイメージをダウンロードし, ブレードサーバへ送信して Singularity を使用する。Singularity を利用する流れを図\ref{fig:singu} に示す。
+ユーザは利用したいイメージをダウンロードし, ブレードサーバへ送信して Singularity を使用する。Singularity を利用する流れを図\ref{fig:singu} に示す。
 
 \begin{figure*}[tb]
     \begin{center}
@@ -339,7 +335,36 @@
 立ち上げはユーザが Web コンソールで CI/CD トークンの設定時に行われる。GitLab Runner をユーザごとに立ち上げることで, 複数のユーザが同時に Build を行うことができる。
 
 \subsection{Kubernetes の操作}
-実装には Kubernetes の操作を行うためのライブラリである client-go \cite{kubecli} を使用する。
+Docker と同様に Kubernetes のすべての操作を必要としないため, Kubernetes と対話するためのライブラリである client-go \cite{kubecli} を使用し, 必要な機能のみを実装する。
+サービスを提供する上で Kubernetes の必要となる操作は以下である。
+
+\begin{itemize}
+  \item コンテナの作成
+  \item コンテナの削除
+  \item 認証トークンの取得
+\end{itemize}
+
+Kubernetes でのコンテナ作成は Pod を作成することである。 Kubernetes でのコンテナ作成は Namespace, Deployment, Service, 
+Ingress の流れでオブジェクトを作成する。コンテナの作成は Docker と同様に表\ref{tb:wmcon} の情報を下に作成する。
+作成するそれぞれのオブジェクト名は Web コンソールで コンテナ名とアカウントID で補完される。また, Namespace はアカウントID となる。
+コンテナの削除にはそれぞれのオブジェクト名と Namespace を用いる。\par
+Kubernetes で作成したコンテナは Web コンソールから操作できないため, digdog でも利用されている RBAC を用いる。
+RBAC で使用する 認証トークンはユーザごとに作成された Namespace に設定されるトークンを返すことで, 他のユーザが認証することはできない。
+またアクセス制御は Namespace ごとに設定されることで, 他のユーザのコンテナを操作することはできない。
+RBAC で許可するリソースの操作は表\ref{tb:wm} である。
+
+\begin{table}[htb]
+  \begin{center}
+  \caption{kubectl のコマンド}
+  \begin{tabular}{c|l} \hline
+    get  & Pod, Deployment, Service, Ingress の一覧を表示する \\ \hline
+    log & Pod の Log を表示する \\ \hline
+    exec & Pod にアクセスする \\ \hline
+    cp & Pod にファイルを送信する \\ \hline
+    \end{tabular}
+  \label{tb:wm}
+  \end{center}
+\end{table}
 
 
 \section{サービスの評価}