Binary file paper/mk-wm.pdf has changed

--- a/paper/mk-wm.tex	Sat Aug 08 19:24:36 2020 +0900
+++ b/paper/mk-wm.tex	Sat Aug 08 21:28:21 2020 +0900
@@ -143,7 +143,7 @@
 
   \item Role
   \begin{itemize}
-      \item Kubernetes API の利用権限を定義する。
+      \item Kubernetes API の利用権限 Namespace ごとに定義する。
   \end{itemize}
 
   \item RoleBinding
@@ -241,10 +241,12 @@
 
 \subsection{コンテナの作成}
 学生または教員は学科アカウントで Web コンソールへログインする。Web コンソールでは ユーザのコンテナ一覧や Docker イメージ一覧を確認することができる。
-コンテナ作成を選択するとコンテナを作成するために必要な情報を入力する。入力する内容は表\ref{tb:wmcon} である。コンテナ名にはユーザのアカウント名が補完されるため, 他のユーザと被ることはない。
+コンテナ作成は Docker コンテナと Kubernetes コンテナの 2つから選択することができる。
+コンテナ作成を選択するとコンテナを作成するために必要な情報を入力する。入力する内容は表\ref{tb:wmcon} である。
+コンテナ名にはユーザのアカウント名が補完されるため, 他のユーザと被ることはない。
 Docker イメージには Docker Hub に登録されているイメージや, ユーザが作成したイメージを入力することができる。環境変数とゲストポートはスペース区切りで複数入力することができる。
 ホストポートは, エフェメラルポートの範囲から設定される。ユーザは設定されたホストポートを使用してコンテナのサービスへアクセスする。
-また, ユーザはコンテナに対して Web コンソールから, または手元の PC から操作することができる。
+また, ユーザは Docker コンテナに対しては Web コンソールから, Kubernetes コンテナには手元の PC から操作することができる。
 必要なくなったコンテナは Web コンソールのコンテナ一覧から削除することができる。
 
 \begin{table}[htb]
@@ -319,14 +321,14 @@
 Docker の操作や Kubernetes の操作を行う HTTP API はセッション管理を行わないため, Web コンソールで管理する必要がある。
 そのため, ユーザのコンテナやイメージの情報をデータベースに格納して管理する。
 ユーザが作成する Docker イメージの情報を取得しユーザのアカウントID と紐付けを行う。また, 作成した Docker イメージは共有することができ, 共有されたイメージはユーザのイメージ一覧とは別の一覧で確認することができる。
-ユーザはコンテナ作成時にイメージを入力することができる。この時, 他のユーザの作成したイメージの場合, そのイメージが共有されたイメージなのか確認を行うことで, 非共有に設定されたイメージではコンテナの作成はできない。
+ユーザはコンテナ作成時にイメージを入力することができる。この時, 他のユーザが作成したイメージの場合, そのイメージが共有されたイメージなのか確認を行うことで, 非共有に設定されたイメージではコンテナの作成はできない。
 コンテナの操作を行う時, コンテナに紐づけられたアカウントID との確認が行われることで, 他のユーザのコンテナを操作することはできない。
 同様にイメージの削除を行う時にもアカウントID の確認が行われる。
 
 \subsection{Docker の操作}
 Docker は Docker Engine API を提供している。Docker デーモンは指定した IP アドレスと ポート を リッスンする。 IP アドレスと ポートの指定を行うことで外部から Docker の操作が可能になる。
 だが, Dockr デーモンが稼働しているホスト上の root アクセスを得られるため, 推奨されてない。
-また, 本論文で実装するサービスでは Docker のすべての操作を必要としない。そこで, Docker の操作を行うための SDK \cite{sdk} を使用し, 必要な機能のみを実装する。\par
+また, 本研究で実装するサービスでは Docker のすべての操作を必要としない。そこで, Docker の操作を行うための SDK \cite{sdk} を使用し, 必要な機能のみを実装する。\par
 サービスを提供する上で Docker の必要となる操作は以下である。
 \begin{itemize}
   \item コンテナの作成
@@ -339,13 +341,13 @@
 
 コンテナは, 表\ref{tb:wmcon} で入力した情報を下に作成を行う。コンテナ名は Web コンソールからリクエストを送るタイミングで補完される。
 また, コンテナが属するネットワーク名も補完される。リクエストは JSON 形式で受け, JSON 形式でレスポンスを返す。
-リクエストからコンテナを作成後, 作成したコンテナID や ネットワークID , コンテナのステータスを返却する。
-返却したコンテナID や ネットワークID を下にコンテナ削除やコマンドの実行, ファイルの送信を処理する。
+リクエストからコンテナを作成後, 作成したコンテナID やネットワークID, コンテナのステータスを返却する。
+返却したコンテナID やネットワークID を下にコンテナ削除やコマンドの実行, ファイルの送信を処理する。
 だが, ファイルの送信では JSON 形式ではなく multipart/form-data 形式でリクエストを受ける。\par
 Docker イメージは GitLab CI/CD を利用して作成するが, ビルドが成功したかを判断することはできない。
 そのため, Web コンソール側から 5 分に一度イメージの更新リクエストを受け, Docker イメージの一覧をリストにまとめ返却を行う。\par
 ユーザが作成するコンテナとは別に GitLab CI/CD で Docker イメージをビルドするための GitLab Runner を立てる必要がある。
-立ち上げはユーザが Web コンソールで CI/CD トークンの設定時に行われる。GitLab Runner をユーザごとに立ち上げることで, 複数のユーザが同時にビルドを行うことができる。
+立ち上げはユーザが Web コンソールで CD トークンの設定時に行われる。GitLab Runner をユーザごとに立ち上げることで, 複数のユーザが同時にビルドを行うことができる。
 
 \subsection{Kubernetes の操作}
 Docker と同様に Kubernetes のすべての操作を必要としないため, Kubernetes と対話するためのライブラリである client-go \cite{kubecli} を使用し, 必要な機能のみを実装する。
@@ -361,7 +363,7 @@
 Ingress の流れでオブジェクトを作成する。コンテナの作成は Docker と同様に表\ref{tb:wmcon} の情報を下に作成する。
 作成するそれぞれのオブジェクト名は Web コンソールで コンテナ名とアカウントID で補完される。また, Namespace はアカウントID となる。
 コンテナの削除にはそれぞれのオブジェクト名と Namespace を用いる。\par
-Kubernetes で作成したコンテナは Web コンソールから操作できないため, digdog でも利用されている RBAC を用いる。
+Kubernetes で作成したコンテナは Web コンソールから操作より, digdog でも利用されている RBAC を用いる方が操作がしやすい。
 RBAC で使用する 認証トークンはユーザごとに作成された Namespace に設定されるトークンを返すことで, 他のユーザが認証することはできない。
 またアクセス制御は Namespace ごとに設定されることで, 他のユーザのコンテナを操作することはできない。
 RBAC で許可するリソースの操作は表\ref{tb:wm} である。
@@ -391,8 +393,7 @@
 VM は OS の仮想化環境を提供するため, ユーザが好みの環境を構築できるなど自由度が高い。\par
 本研究で実装したサービスでは, Docker イメージで構築されたアプリケーションに限定される。
 また, ユーザが欲しい環境は Docker イメージを作成しなければいけないため, Docker について学習する必要がある。
-だが, VM と違い気軽に環境の構築やテストを行える。
-また Docker イメージを共有することで, 自身と同じ環境を他のユーザに利用してもらえるなどの良さがある。
+だが, VM と違いコンテナを作成することで開発環境の構築やテスト, またイメージを共有することで同じ環境を他のユーザが利用することができる良さがある。
 
 \subsection{ie-docker}
 ie-docker は Docker をラップしたツールであり, ユーザは学科のブレードサーバへ ssh で接続を行い CUI から利用することができる。
@@ -418,10 +419,10 @@
 \section{今後の課題}
 本研究で実装したサービスでは学生が学習環境として利用するには, まだ必要な実装が不足している。\par
 本サービスでは, 大量のデータを用いる時に Singularity を使用できる環境を用意している。だが, Web コンソールから作成した Docker や Kubernetes のコンテナでは
-データの永続化が対応していないため, コンテナの削除時に共に削除されてしまう。学科のブレードサーバでは学生用ディレクトリがある。
+データの永続化が対応していないため, コンテナの削除時に共に削除されてしまう。学科のブレードサーバでは学生ごとのディレクトリがある。
 Docker ではそのディレクトリをコンテナ立ち上げ時にマウントすることで, コンテナ内のデータの永続化に対応できる。
-また, Kubernetes では Peresistent Volumes という永続ボリュームの仕組みがある。この Peresistent Volumes をユーザごとに管理することで, コンテナのデータの永続化に対応できる。
-このような対策でコンテナでデータの永続化に対応できるが, コンテナごとにデータの保存場所が違うなどの問題があるため, データを管理する仕組みが必要だと考える。\par
+また, Kubernetes では Peresistent Volumes という永続ボリュームの仕組みがある。この Peresistent Volumes をユーザごとに管理することで, コンテナ内のデータの永続化に対応できる。
+このような対策でコンテナ内のデータの永続化に対応できるが, コンテナごとにデータの保存場所が違うなどの問題があるため, データを管理する仕組みが必要だと考える。\par
 本サービスでは, 学生が自由に Docker イメージを作成できる。また, Docker イメージを Singularity 用のイメージに変換する。
 そのため, イメージの容量でブレードサーバのストレージを圧迫してしまう可能性があることから, 定期的にイメージを削除する必要がある。
 また, 本サービスではユーザごとにリソースの制限を行っていないため, 過剰なリソースの占有を防ぐための対策をする必要がある。
@@ -434,7 +435,7 @@
 本稿では, 本コースで利用する新規サービスの設計と実装, また本コースで利用しているサービスとの比較を行った。
 学生がコンテナ技術を用いて学習環境を利用できるサービスの設計をし, マルチユーザ環境に対応した実装をすることができた。
 学生は学科アカウントを持っていれば, Web コンソールからコンテナの作成ができる。
-また, GitLab CI/CD を利用し Dockerfile から Docker イメージをビルドすることができ, イメージの作成を学ぶこともできる。\par
+また, GitLab CI/CD を利用し Dockerfile から Docker イメージをビルドすることで, イメージの作成を学ぶこともできる。\par
 今後, テスト環境にデプロイを行い, ユーザやシステム管理チームからのフィードバックをもらい, 改善や実証実験を目指す。
 
 \nocite{*}