Mercurial > hg > Papers > 2020 > mk-midterm

changeset 5:c35b0890b779

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
update tex
author Ken Miyahira <e175733@ie.u-ryukyu.ac.jp>
date Mon, 14 Sep 2020 23:23:22 +0900
parents 22f062ff21a2
children 5f52fac4bacf
files mid_thesis.pdf mid_thesis.tex
diffstat 2 files changed, 74 insertions(+), 319 deletions(-) [+]
line wrap: on
line diff
Binary file mid_thesis.pdf has changed
--- a/mid_thesis.tex	Mon Sep 14 22:54:03 2020 +0900
+++ b/mid_thesis.tex	Mon Sep 14 23:23:22 2020 +0900
@@ -11,25 +11,18 @@
 
 \title{情報工学科演習用のコンテナ技術を用いたサービスの設計・実装 \\
        Design and Implementation of service using container technology for Information science exercise}
-\author{175733E 氏名 {宮平 賢}{Miyahira Ken} 指導教員 : {河野 真治} }
+\author{175733E 氏名 {宮平 賢} 指導教員 : {河野 真治} }
 %\date{}
 
 \maketitle
 %\begin{abstract}
 %情報技術の普及に伴い情報系の学生が課題や演習を行う学習環境が必要である。
-%学習環境を複数の学生に提供する方法として, VM や コンテナがある。
+%学習環境を複数の学生に提供する方法として，VM や コンテナがある。
 %琉球大学工学部では VM 貸出サービスがある。
 %課題や演習によっては CPU より GPU が必要となる場合がある。
-%しかし, 本コースの VM 貸出サービスは GPU の共有に対応していない。
-%そこで, コンテナ仮想化技術を利用できる Docker と Kubernetes, Singularity を用いて, GPU を含む学習環境を提供する。
+%しかし，本コースの VM 貸出サービスは GPU の共有に対応していない。
+%そこで，コンテナ仮想化技術を利用できる Docker と Kubernetes，Singularity を用いて，GPU を含む学習環境を提供する。
 %本稿では学習環境を提供するサービスの設計・実装を行う。
-%
-%この学習環境では, 課題や演習によっては並列処理により, CPU より GPU が必要となる場合がある。
-%このような学習環境を複数の学生に提供する方法として, VM や コンテナがある。
-%しかし, 琉球大学工学部で運用している VM 貸出サービスでは, GPU の共有に対応していない。
-%また, PC 上からコンテナへの操作を可能にするために Kubernetes でのコンテナ作成にも対応する。
-%コンテナ貸出サービスは LDAP で管理された学生のアカウントを使用することで, 適切にコンテナの管理を行う。
-%本稿ではサービスを実装する上で必要な技術概要を延べ, サービスの設計・実装を行う。
 %\end{abstract}
 
 
@@ -39,7 +32,7 @@
 There are VMs and containers as a way to provide a learning environment for students. 
 The University of the Ryukyus has a VM rental service. Some assignments and exercises require GPUs rather than CPUs. 
 However, the VM rental service in this course does not support GPU sharing. 
-Therefore, we provide a learning environment that includes GPUs by using Docker, Kubernetes and Singularity, which can utilize container virtualization technologies. 
+Therefore, we provide a learning environment that includes GPUs by using Docker, Kubernetes, and Singularity, which can utilize container virtualization technologies. 
 In this paper, we design and implement a service that provides a learning environment.
 \end{abstract}
 
@@ -47,134 +40,66 @@
 
 \begin{multicols*}{2}
 \section{コンテナ技術を用いた学習環境の提供}
-情報通信技術の普及に伴い学生が学ぶ学習環境が必要となる。その学習環境として VM や コンテナにより, 手軽に開発し試せる技術が普及している。
-だが, 手元の PC 上で VM や コンテナを立ち上げ, 開発を行うことはできるが, VM や コンテナの使用には高性能 PC や 有料のクラウドサービスが必要になる場合がある。
+情報通信技術の普及に伴い学生が学ぶ学習環境が必要となる。その学習環境として VM や コンテナにより，手軽に開発し試せる技術が普及している。
+だが，手元の PC 上で VM や コンテナを立ち上げ，開発を行うことはできるが，VM や コンテナの使用には高性能 PC や 有料のクラウドサービスが必要になる場合がある。
 この大きな負担を学生に負わせない仕組みが必要である。
 \par
 本コースでは希望する学生に学科のブレードサーバから仮想環境を貸出すサービスを行なっている。
-貸出 VM スペックは CPU 1コア, メモリ 1GB, ストレージ 10GB である。
-このスペックで不足する場合, 要望に応じてスペックの変更を行なっている。
-だが, 貸出 VM でも課題によっては処理に時間がかかることがある。
-例として, 人工知能の講義において課される課題においては CPU より GPU が必要となる場合がある。
-しかし, 現在の VM 貸出サービスでは GPU の共有に対応していない。
-VM 上で GPU を共有するには PCI パススルーを利用することで可能だが, PCI パススルーでは複数の VM に共有することができない。
-そこで, GPU を含めた学習環境をコンテナ技術を用いて提供するサービスの設計・実装を行う。
+貸出 VM スペックは CPU 1コア，メモリ 1GB，ストレージ 10GB である。
+このスペックで不足する場合，要望に応じてスペックの変更を行なっている。
+だが，貸出 VM でも課題によっては処理に時間がかかることがある。
+例として，人工知能の講義において課される課題においては CPU より GPU が必要となる場合がある。
+しかし，現在の VM 貸出サービスでは GPU の共有に対応していない。
+VM 上で GPU を共有するには PCI パススルーを利用することで可能だが，PCI パススルーでは複数の VM に共有することができない。
+そこで，GPU を含めた学習環境をコンテナ技術を用いて提供するサービスの設計・実装を行う。
 
 \vspace{-2zh}
 
 \section{技術概要}
-本研究で使用したコンテナ仮想化技術,　また本コースで利用しているサービスについての概要を説明する。
+本研究で使用したコンテナ仮想化技術，また本コースで利用しているサービスについての概要を説明する。
 
 \subsection{Docker}
-Docker とは OS レベルの仮想化技術を利用して, ソフトウェアをコンテナと呼ばれるパッケージで提供する。またコンテナの実行だけでなく, 
-コンテナの実行に用いるイメージの作成, イメージを共有する仕組みを持つコンテナ管理ソフトウェアである。
-コンテナの実行には Docker 社が提供している Docker Hub\cite{dockerhub} に登録されているイメージ, Dockerfile を用いて作成したイメージを利用することができる。
-Dockerfile を用いることで, 必要なソフトウェアや各種設定を含んだイメージを作成できる。
+Docker とは OS レベルの仮想化技術を利用して，ソフトウェアをコンテナと呼ばれるパッケージで提供する。またコンテナの実行だけでなく，
+コンテナの実行に用いるイメージの作成，イメージを共有する仕組みを持つコンテナ管理ソフトウェアである。
+コンテナの実行には Docker 社が提供している Docker Hub\cite{dockerhub} に登録されているイメージ，Dockerfile を用いて作成したイメージを利用することができる。
+Dockerfile を用いることで，必要なソフトウェアや各種設定を含んだイメージを作成できる。
 
 \subsection{Kubernetes}
-Kubernetes\cite{k8s} とは, アプリケーションのデプロイ, スケーリング, 及び管理を用意にするためのコンテナを動的管理するコンテナオーケストレーションである。
-Kubernetes ではオブジェクトによりクラスターの状態を表現する。オブジェクトはコンテナだけでなく, ネットワークやストレージ, 接続ポリシーの望ましい状態を記述できる。
-%本研究では以下のオブジェクトを主に利用する。
-%\begin{itemize}
-%  \item Pod
-%  \begin{itemize}
-%      \item Kubernetes で作成, 管理できる最小単位。Pod 内に 1 つ以上のコンテナを起動できる。
-%  \end{itemize}
-%
-%  \item ReplicaSet 
-%  \begin{itemize}
-%      \item 安定した Pod の維持を行い, クラスタで必要な Pod 数を管理する。Pod のセルフヒーリングを行う。
-%  \end{itemize}
-%
-%  \item Deployment
-%  \begin{itemize}
-%      \item ReplicaSet のロールアウトを図るなど, 管理を行う。
-%  \end{itemize}
-%
-%  \item Service
-%  \begin{itemize}
-%      \item Pod にアクセスするための IP アドレスやポートを割り振る。
-%  \end{itemize}
-%
-%  \item Ingress
-%  \begin{itemize}
-%      \item 外部からのアクセスを管理する。負荷分散, SSL 終端, 名前ベースの仮想ホスティングの機能を提供する。
-%  \end{itemize}
-%
-%  \item Namespace
-%  \begin{itemize}
-%      \item 仮想クラスタとしてグループ化して取り扱える。
-%  \end{itemize}
-%
-%  \item Role
-%  \begin{itemize}
-%      \item Kubernetes API の利用権限 Namespace ごとに定義する。
-%  \end{itemize}
-%
-%  \item RoleBinding
-%  \begin{itemize}
-%      \item ユーザやグループに Role を関連付ける。
-%  \end{itemize}
-%\end{itemize}
+Kubernetes\cite{k8s} とは，アプリケーションのデプロイ，スケーリング，及び管理を用意にするためのコンテナを動的管理するコンテナオーケストレーションである。
+Kubernetes ではオブジェクトによりクラスターの状態を表現する。オブジェクトはコンテナだけでなく，ネットワークやストレージ，接続ポリシーの望ましい状態を記述できる。
 
 \subsection{Singularity}
-Singularity とは, HPC クラスタ上で複雑なアプリケーションを実行するために開発されたコンテナプラットフォームである。
-Singularity は マルチユーザに対応しており, コンテナ内での権限は実行ユーザの権限を引き継ぐため, ユーザに特別な権限の設定が必要ない。
-またデフォルトで, \$HOME, /tmp, /proc, /sys, /dev がコンテナにマウントされ, サーバ上の GPU を簡単に利用できる。
-Singularity のコンテナイメージは Docker Hub に登録されているイメージ, またはDockerfile から作成したイメージを変換することで利用することができる。
+Singularity とは，HPC クラスタ上で複雑なアプリケーションを実行するために開発されたコンテナプラットフォームである。
+Singularity は マルチユーザに対応しており，コンテナ内での権限は実行ユーザの権限を引き継ぐため，ユーザに特別な権限の設定が必要ない。
+またデフォルトで，\$HOME，/tmp，/proc，/sys，/dev がコンテナにマウントされ，サーバ上の GPU を簡単に利用できる。
+Singularity のコンテナイメージは Docker Hub に登録されているイメージ，またはDockerfile から作成したイメージを変換することで利用することができる。
 
 \subsection{GitLab}
 GitLab\cite{gitlab} とは バージョン管理システムである Git のリポジトリマネージャである。
-GitLab は GitHub と違い, オンプレミス環境に構築することができるため, 本コースでは GitLab を使用している。
-本研究では GitLab の統合機能の GitLab CI/CD\cite{gitlabcicd}, また GitLab CI/CD と組み合わせて使用する GitLab Runner\cite{gitlabrunner} を利用する。\par
+GitLab は GitHub と違い，オンプレミス環境に構築することができるため，本コースでは GitLab を使用している。
+本研究では GitLab の統合機能の GitLab CI/CD\cite{gitlabcicd}，また GitLab CI/CD と組み合わせて使用する GitLab Runner\cite{gitlabrunner} を利用する。\par
 GitLab CI/CD は 継続的インテグレーション(CI)・継続的デリバリー(CD)を GitLab から利用することができる。
-CI では GitLab のコードを定期的または自動的にビルド・テストを行う。CD は CI を拡張した機能であり, ビルドやテストだけでなくリリースの準備も行う。
-%本コースでは, Operating System という講義で Mercurial と Jenkins を利用してコードのテストを行う課題などがある。
+CI では GitLab のコードを定期的または自動的にビルド・テストを行う。CD は CI を拡張した機能であり，ビルドやテストだけでなくリリースの準備も行う。
 \par
-GitLab Runner とは, ビルドのためのアプリケーションであり, GitLab CI と連携することで別の場所でビルドを動かすことができる。
+GitLab Runner とは，ビルドのためのアプリケーションであり，GitLab CI と連携することで別の場所でビルドを動かすことができる。
 
-%\subsection{Kernel-based Virtual Machine (KVM)}
-%KVM\cite{kvm} とは, Linux 自体を VM の実行基盤として機能させるソフトウェアである。
-%CPU の仮想化支援機能を必要とし, 完全仮想化により OS の仮想化環境を提供する。
-%
-%\subsection{ie-virsh}
-%ie-virsh\cite{ie-virsh} とは, 本コースの Operating System という講義に向けに libvirt の CLI である virsh をラップし複数のユーザで利用することができる VM 管理ツールである。
-%学生が手元の PC で作成した VM をブレードサーバ上にデプロイすることができる。
-%
-%\subsection{ie-docker}
-%ie-docker とは Docker をラップし複数のユーザで利用することのできるコンテナ管理ツールである。
-%利用する学生は ssh でブレードサーバへ接続し, ie-docker を使用してコンテナを操作することができる。
-%
 \subsection{digdog}
 digdog\cite{digdog} とは Kubernetes を利用し Web コンソールからコンテナを作成することができるコンテナ貸出サービスである。
-学生は学科アカウントを使用して Web サービスへログインし, 登録されている Docker イメージでコンテナを作成することができる。
+学生は学科アカウントを使用して Web サービスへログインし，登録されている Docker イメージでコンテナを作成することができる。
 
 \section{サービスの設計}
-%サービスでは本コースの学生や教員がにコンテナ貸出を行う。このコンテナ貸出の構成を図\ref{fig:wm} に示し, 概要を以下で説明する。
-
-サービスは本コースの学生や教員が利用する。そのため, ユーザが他のユーザのコンテナの削除などの操作を行えないように制限をするなどの, マルチユーザ環境へ対応する必要がある。
-また, 管理者にコンテナで利用するイメージを用意してもらうのではなく, 利用したい学習環境をユーザが構築できる仕組みが必要である。
-GPU を含む学習環境を提供するために, 複数のコンテナへ GPU を共有できる仕組み, またコンテナへのファイルの共有ができる仕組みが必要となる。
-
-%コンテナによる学習環境にあたっては以下の用件が必要となる。
-%
-%\begin{itemize}
-%  \setlength{\parskip}{0cm} % 段落間
-%  \setlength{\itemsep}{0cm} % 項目間
-%  \item マルチユーザへの対応
-%  \item イメージを自由に作成できる
-%  \item GPU が利用できる
-%  \item コンテナへファイルの共有ができる
-%\end{itemize}
+サービスは本コースの学生や教員が利用する。そのため，ユーザが他のユーザのコンテナの削除などの操作を行えないように制限をするなどの，マルチユーザ環境へ対応する必要がある。
+また，管理者にコンテナで利用するイメージを用意してもらうのではなく，利用したい学習環境をユーザが構築できる仕組みが必要である。
+GPU を含む学習環境を提供するために，複数のコンテナへ GPU を共有できる仕組み，またコンテナへのファイルの共有ができる仕組みが必要となる。
 
 \subsection{マルチユーザへの対応}
 Docker は基本的に root 権限で動作する。また一般ユーザが docker コマンドを使用するには docker グループに追加する必要がある。
-そのため docker グループに追加されたユーザは, 他ユーザのコンテナを操作できるなどセキュリティ上の問題がある。
+そのため docker グループに追加されたユーザは，他ユーザのコンテナを操作できるなどセキュリティ上の問題がある。
 \par
-そこで, Web コンソールを用いて管理を行う。 Web コンソールには学科のアカウントを用いてログインし, コンテナの作成や操作を可能とする。
+そこで，Web コンソールを用いて管理を行う。 Web コンソールには学科のアカウントを用いてログインし，コンテナの作成や操作を可能とする。
 コンテナ作成は Docker コンテナと Kubernetes コンテナの 2つから選択することができる。
 コンテナ作成を選択するとコンテナを作成するために必要な情報を入力する。入力する内容は表\ref{tb:wmcon} である。
-作成時にコンテナ名をユーザのアカウント名で補完されるため, 他のユーザと被ることはない。
+作成時にコンテナ名をユーザのアカウント名で補完されるため，他のユーザと被ることはない。
 
 \begin{table}[H]
   \begin{center}
@@ -190,42 +115,13 @@
   \end{center}
 \end{table}
 
-%\subsection{コンテナの作成}
-%学生または教員は学科アカウントで Web コンソールへログインする。Web コンソールでは ユーザのコンテナ一覧や Docker イメージ一覧を確認することができる。
-%コンテナ作成は Docker コンテナと Kubernetes コンテナの 2つから選択することができる。
-%コンテナ作成を選択するとコンテナを作成するために必要な情報を入力する。入力する内容は表\ref{tb:wmcon} である。
-%コンテナ名にはユーザのアカウント名が補完されるため, 他のユーザと被ることはない。
-%Docker イメージには Docker Hub に登録されているイメージや, ユーザが作成したイメージを入力することができる。
-%環境変数とゲストポートはスペース区切りで複数入力することができる。
-%また, コンテナ内で GPU を使用するにはチェックボックスにチェックを入れる。
-%ホストポートは, エフェメラルポートの範囲から設定される。ユーザは設定されたホストポートを使用してコンテナのサービスへアクセスする。
-%また, ユーザは Docker コンテナに対しては Web コンソールから, Kubernetes コンテナには手元の PC から操作することができる。
-%必要なくなったコンテナは Web コンソールのコンテナ一覧から削除することができる。
-%
-%\begin{table}[H]
-%  \begin{center}
-%  \caption{コンテナ作成時の入力内容}
-%  \begin{tabular}{c|l} \hline
-%    ContainerName  & コンテナ名 \\ \hline
-%    Image & Docker イメージ \\ \hline
-%    Environments & コンテナ作成時の環境変数 \\ \hline
-%    GuestPort & コンテナが使用するポート番号 \\ \hline
-%    GPU & GPU を使用するか \\ \hline
-%    \end{tabular}
-%  \label{tb:wmcon}
-%  \end{center}
-%\end{table}
-
 \subsection{イメージの作成}
 Docker イメージの作成は学科で使用している GitLab の CI/CD の CI 機能を利用する。ユーザがイメージを作成する流れを図\ref{fig:gitlab} に示す。
-ユーザは学科 GitLab から CI トークンを取得し, Web コンソールに取得したトークンをセットする。この時 Docker 側に GitLab Runner の立ち上げを依頼する。
-トークンの設定後, Web コンソールから CI 用の YAML ファイルをダウンロードし Dockerfile と一緒に学科 GitLab のリポジトリにプッシュする。
+ユーザは学科 GitLab から CI トークンを取得し，Web コンソールに取得したトークンをセットする。この時 Docker 側に GitLab Runner の立ち上げを依頼する。
+トークンの設定後，Web コンソールから CI 用の YAML ファイルをダウンロードし Dockerfile と一緒に学科 GitLab のリポジトリにプッシュする。
 GitLab にプッシュした Dockerfile が GitLab Runner 上でビルドされる。
-ビルドの成否は GitLab から確認することができ, 作成されたイメージは Web コンソールから確認することができる。
-GitLab の CI/CD 機能を利用することで, 学生に権限を与えることなくイメージの作成を行うことが可能となる。
-
-%Docker イメージのビルドが成功すると Web コンソールのイメージ一覧で確認ができる。作成した Docker イメージは編集からイメージの使い方の記述や他の学生に共有するか設定を行える。
-%必要なくなったイメージは Web コンソールのイメージ一覧から削除することができる。
+ビルドの成否は GitLab から確認することができ，作成されたイメージは Web コンソールから確認することができる。
+GitLab の CI/CD 機能を利用することで，学生に権限を与えることなくイメージの作成を行うことが可能となる。
 
 \begin{figure}[H]
     \begin{center}
@@ -237,19 +133,19 @@
 
 \subsection{GPU の利用}
 GPU を使った学習を行うには NVIDIA Container Toolkit である nvidia-docker\cite{nvidia-docker} を利用する。
-nvidia-docker を導入することで, GPU を利用するための環境が整っている nvidia/cuda イメージを利用することが可能となる。
+nvidia-docker を導入することで，GPU を利用するための環境が整っている nvidia/cuda イメージを利用することが可能となる。
 GPU を使った学習環境を利用するには nvidia/cuda でイメージを作成する。
 作成したイメージをコンテナ作成時の表\ref{tb:wmcon} の Docker イメージに入力する。
-また GPU を利用するかのチェックを入れることで, コンテナへ GPU を共有することが可能となる。
+また GPU を利用するかのチェックを入れることで，コンテナへ GPU を共有することが可能となる。
 
 \subsection{ファイルの共有}
-コンテナに大量のデータを送信する必要がある場合や, データを永続化させたい場合に Singularity を利用する。
-Singularity はユーザ権限で動作することから, 学生が ssh でブレードサーバへ接続し利用する方が適している。
+コンテナに大量のデータを送信する必要がある場合や，データを永続化させたい場合に Singularity を利用する。
+Singularity はユーザ権限で動作することから，学生が ssh でブレードサーバへ接続し利用する方が適している。
 Singularity は Docker イメージを変換し使用できる。
-だが, イメージの変換には sudo 権限が必要となる。
-%Docker イメージの変換を申請性にすると, 管理者の仕事が増え, またユーザも利用しづらい。
-そこで, Web コンソールから Singularity 用のイメージをダウンロードできる仕様とする。\par
-ユーザは利用したいイメージをダウンロードし, ブレードサーバへ送信して Singularity を使用する。Singularity を利用する流れを図\ref{fig:singu} に示す。
+だが，イメージの変換には sudo 権限が必要となる。
+%Docker イメージの変換を申請性にすると，管理者の仕事が増え，またユーザも利用しづらい。
+そこで，Web コンソールから Singularity 用のイメージをダウンロードできる仕様とする。\par
+ユーザは利用したいイメージをダウンロードし，ブレードサーバへ送信して Singularity を使用する。Singularity を利用する流れを図\ref{fig:singu} に示す。
 
 \begin{figure}[H]
     \begin{center}
@@ -260,19 +156,12 @@
 \end{figure}
 
 \section{サービスの実装}
-%本コースでは学科システムを教員の指導の下, 学生主体でシステム管理チームと呼ばれる組織によって構築・運用・管理が行われている。
-%学科システムはブレードサーバを 4 台, SAN 用ストレージと汎用ストレージをそれぞれ 2台ずつ導入している。本コースの基幹サービスはこのブレードサーバの仮想環境上で VM として動作している。
-%新たにサービスを実装するとなると, システム管理チームが運用・管理を行いやすい実装にする必要がある。\par
-%Web コンソールや Docker の操作を 1 つにまとめると, Docker コンテナの作成が 1台のブレードサーバのみになってしまう。
-%そこで, コンテナ貸出システムは, 機能ごとに以下の 3 つにサービスに分ける。
-%Docker や Kubernetes の操作を HTTP API で提供することにより, リクエスト先を変更することで複数のブレードサーバにコンテナを分散することができる。
-%だが, 現時点では未実装である。
 
 サービスのシステム構成を図\ref{fig:wm} に示す。
-Web コンソールで Docker や Kubernetes の操作をまとめるのではなく, 機能ごとに以下の 3 つにサービスを分ける。
+Web コンソールで Docker や Kubernetes の操作をまとめるのではなく，機能ごとに以下の 3 つにサービスを分ける。
 Web コンソールから HTTP API で各機能へリクエストを送信し操作を行う。
 \par
-実装にはDocker や Kubernetes の実装言語であり, 操作するためのライブラリが揃っている Go 言語を使用する。
+実装にはDocker や Kubernetes の実装言語であり，操作するためのライブラリが揃っている Go 言語を使用する。
 \begin{itemize}
   \setlength{\parskip}{0cm} % 段落間
   \setlength{\itemsep}{0cm} % 項目間
@@ -290,20 +179,15 @@
 \end{figure*}
 
 \subsection{Web コンソール}
-Web コンソールは本コースの学生や教員が利用するため, 学科アカウントでログインできる必要がある。学科の LDAP サーバを利用して学科アカウントで LDAP 認証を実装する。\par
-%Docker の操作や Kubernetes の操作を行う HTTP API はセッション管理を行わないため, Web コンソールで管理する必要がある。
-Docker の操作や Kubernetes の操作を行う機能では, ユーザの管理を行わないため Web コンソールで管理する必要がある。
-そのため, ユーザのコンテナやイメージの情報をデータベースに格納して管理する。
-ユーザがコンテナやイメージの操作を行う時は, 紐づけられたアカウントID の確認を行うことで, 他のユーザのコンテナやイメージの操作を制限する。
-%ユーザが作成する Docker イメージの情報を取得しユーザのアカウントID と紐付けを行う。また, 作成した Docker イメージは共有することができ, 共有されたイメージはユーザのイメージ一覧とは別の一覧で確認することができる。
-%ユーザはコンテナ作成時にイメージを入力することができる。この時, 他のユーザが作成したイメージの場合, そのイメージが共有されたイメージなのか確認を行うことで, 非共有に設定されたイメージではコンテナの作成はできない。
-%コンテナの操作を行う時, コンテナに紐づけられたアカウントID との確認が行われることで, 他のユーザのコンテナを操作することはできない。
-%同様にイメージの削除を行う時にもアカウントID の確認が行われる。
+Web コンソールは本コースの学生や教員が利用するため，学科アカウントでログインできる必要がある。学科の LDAP サーバを利用して学科アカウントで LDAP 認証を実装する。\par
+Docker の操作や Kubernetes の操作を行う機能では，ユーザの管理を行わないため Web コンソールで管理する必要がある。
+そのため，ユーザのコンテナやイメージの情報をデータベースに格納して管理する。
+ユーザがコンテナやイメージの操作を行う時は，紐づけられたアカウントID の確認を行うことで，他のユーザのコンテナやイメージの操作を制限する。
 
 \subsection{Docker の操作}
 Docker は Docker Engine API を提供している。Docker デーモンは指定した IP アドレスと ポート を リッスンする。 IP アドレスと ポートの指定を行うことで外部から Docker の操作が可能になる。
-だが, Dockr デーモンが稼働しているホスト上の root アクセスを得られるため, 推奨されてない。
-また, 本研究で実装するサービスでは Docker のすべての操作を必要としない。そこで, Docker の操作を行うための SDK \cite{sdk} を使用し, 必要な機能のみを実装する。\par
+だが，Dockr デーモンが稼働しているホスト上の root アクセスを得られるため，推奨されてない。
+また，本研究で実装するサービスでは Docker のすべての操作を必要としない。そこで，Docker の操作を行うための SDK \cite{sdk} を使用し，必要な機能のみを実装する。\par
 サービスを提供する上で Docker の必要となる操作は以下である。
 \begin{itemize}
   \setlength{\parskip}{0cm} % 段落間
@@ -317,20 +201,10 @@
 \end{itemize}
 
 Web コンソールから JSON 形式でリクエストを受信する。このリクエストを元に上記の操作を行う。
-だが, ファイルの送信では JSON 形式ではなく, multipart/form-data 形式でリクエストを受ける。
-
-%コンテナは, 表\ref{tb:wmcon} で入力した情報を下に作成を行う。コンテナ名は Web コンソールからリクエストを送るタイミングで補完される。
-%また, コンテナが属するネットワーク名も補完される。リクエストは JSON 形式でやり取りを行う。
-%リクエストからコンテナを作成後, 作成したコンテナID やネットワークID, コンテナのステータスを返却する。
-%返却したコンテナID やネットワークID を下にコンテナ削除やコマンドの実行, ファイルの送信を処理する。
-%ファイルの送信では JSON 形式ではなく multipart/form-data 形式でリクエストを受ける。
-%ユーザが作成するコンテナとは別に, GitLab CI/CD で Docker イメージをビルドするための GitLab Runner を立てる必要がある。
-%立ち上げはユーザが Web コンソールで CD トークンの設定時に行われる。GitLab Runner をユーザごとに立ち上げることで, 複数のユーザが同時にビルドを行うことができる。\par
-%Docker イメージは GitLab CI/CD を利用して作成するが, ビルドが成功したかを判断することはできない。
-%そのため, Web コンソール側から 5 分に一度イメージの更新リクエストを受け, Docker イメージの一覧をリストにまとめ返却を行う。\par
+だが，ファイルの送信では JSON 形式ではなく，multipart/form-data 形式でリクエストを受ける。
 
 \subsection{Kubernetes の操作}
-Docker と同様に Kubernetes のすべての操作を必要としないため, Kubernetes と対話するためのライブラリである client-go \cite{kubecli} を使用し, 必要な機能のみを実装する。
+Docker と同様に Kubernetes のすべての操作を必要としないため，Kubernetes と対話するためのライブラリである client-go \cite{kubecli} を使用し，必要な機能のみを実装する。
 サービスを提供する上で Kubernetes の必要となる操作は以下である。
 
 \begin{itemize}
@@ -341,27 +215,17 @@
   \item 認証トークンの取得
 \end{itemize}
 
-Docker と同様に Web コンソールから JSON 形式でリクエストを受信し, リクエストを元に上記の操作を行う。
-Kubernetes ではコンテナへのコマンドの実行やファイルの送信は実装せず, 認証のトークンを取得する機能を実装する。
-Kubernetes では, Kubernetes API の利用権限 Namespace ごとに定義する Role, ユーザやグループに Role を関連付ける RoleBinding がある。
+Docker と同様に Web コンソールから JSON 形式でリクエストを受信し，リクエストを元に上記の操作を行う。
+Kubernetes ではコンテナへのコマンドの実行やファイルの送信は実装せず，認証のトークンを取得する機能を実装する。
+Kubernetes では，Kubernetes API の利用権限 Namespace ごとに定義する Role，ユーザやグループに Role を関連付ける RoleBinding がある。
 この Role と RoleBinding を用いた Role-based access control (RBAC) を利用することで手元の PC からコンテナに対して操作を行うことが可能となる。
-そのため, RBAC への認証トークンを取得する。RBAC で許可するリソースの操作は表\ref{tb:wm} である。
-
-%Kubernetes でのコンテナ作成は Pod を作成することである。 Kubernetes でのコンテナ作成は Namespace, Deployment, Service, 
-%Ingress の流れでオブジェクトを作成する。コンテナの作成は Docker と同様に表\ref{tb:wmcon} の情報を下に作成する。
-%作成するそれぞれのオブジェクト名は Web コンソールでコンテナ名とアカウントID で補完される。また, Namespace はアカウントID となる。
-%コンテナの削除にはそれぞれのオブジェクト名と Namespace を用いる。\par
-%Kubernetes で作成したコンテナは Web コンソールからコマンドの実行やファイルの送信などの操作を行わず, Role と RoleBinding を用いた Role-based access control (RBAC) 
-%を利用することで手元の PC より操作を行うこととする。
-%RBAC で使用する認証トークンはユーザごとに作成された Namespace に設定されるトークンを返すことで, 他のユーザが認証することはできない。
-%またアクセス制御は Namespace ごとに設定されることで, 他のユーザのコンテナを操作することはできない。
-%RBAC で許可するリソースの操作は表\ref{tb:wm} である。
+そのため，RBAC への認証トークンを取得する。RBAC で許可するリソースの操作は表\ref{tb:wm} である。
 
 \begin{table}[H]
   \begin{center}
   \caption{kubectl のコマンド}
   \begin{tabular}{c|l} \hline
-    get  & Pod, Deployment, Service, Ingress の一覧を表示する \\ \hline
+    get  & Pod，Deployment，Service，Ingress の一覧を表示する \\ \hline
     log & Pod の Log を表示する \\ \hline
     exec & Pod にアクセスする \\ \hline
     cp & Pod にファイルを送信する \\ \hline
@@ -370,135 +234,26 @@
   \end{center}
 \end{table}
 
-%\section{サービスの評価}
-
-%\section{他のサービスとの比較}
-%今回作成した Web サービスは主に学生の学習環境をコンテナ技術を利用して提供する。
-%そこで, これまで本コースで使用されてきたサービス, また近年普及しているクラウドサービスと比較する。
-%
-%\subsection{ie-virsh}
-%ie-virsh は手元の PC で作成した VM を学科のブレードサーバにデプロイできるサービスである。
-%ie-virsh は ユーザの UID 及び GID 情報を取得することで, 他のユーザの VM を操作させない。表\ref{tb:ie-virsh}は ユーザが利用できる ie-virsh の機能である。
-%ie-virsh では VM の実行環境を提供するため, ユーザが好みの VM を構築できるなど自由度が高い。\par
-%本研究で実装したサービスでは, コンテナ作成に使用する Docker イメージで構築されたアプリケーションに限定される。
-%また, ユーザが欲しい環境は Docker イメージを作成しなければいけないため, Docker について学習する必要がある。
-%だが, コンテナは VM と違い開発環境やテスト環境の構築の容易さや, 他のユーザにイメージを共有することで同じ環境を利用することができるなどの良さがある。
-%
-%\begin{table}[htb]
-%  \begin{center}
-%  \caption{ie-virsh のコマンド}
-%  \begin{tabular}{c|l} \hline
-%    define  & XML の template を下に domain を作成 \\ \hline
-%    undefine & define で作成した domain を削除 \\ \hline
-%    list & define で作成した domain の一覧表示 \\ \hline
-%    start & 指定した domain 名の VM を起動 \\ \hline
-%    destroy & 指定した domain 名の VM を停止 \\ \hline
-%    dumpxml & domain の XML を参照 \\ \hline
-%    \end{tabular}
-%  \label{tb:ie-virsh}
-%  \end{center}
-%\end{table}
-%
-%\subsection{ie-docker}
-%ie-docker は Docker をラップしたツールであり, ユーザは学科のブレードサーバへ ssh で接続を行い CUI から利用することができる。
-%ie-docker は ユーザの UID 及び GID 情報を取得することで, 他のユーザのコンテナを操作させない。
-%表\ref{tb:ie-docker} は ie-docker で利用できる機能である。
-%この機能を使用しコンテナ作成などの操作を行うことができる。
-%だが, ie-docker ではユーザがコンテナで使用するイメージを管理者が用意する必要がある。
-%そのため, コンテナで使用したいイメージが用意されていないなどの問題があった。\par
-%本研究で実装したサービスでは, コンテナで使用するイメージは Docker Hub に登録されているイメージ, または作成したイメージを利用することができる。
-%ユーザが Docker イメージを作成できることで管理者の負担が少なくなると考える。
-%
-%\begin{table}[htb]
-%  \begin{center}
-%  \caption{ie-docker のコマンド}
-%  \begin{tabular}{c|l} \hline
-%    ps  & 起動中のコンテナの一覧を表示する \\ \hline
-%    run & コンテナを作成する \\ \hline
-%    start & コンテナを起動する \\ \hline
-%    stop & コンテナを停止する \\ \hline
-%    attach & 起動しているコンテナに attach する \\ \hline
-%    cp & コンテナにファイルを送信する \\ \hline
-%    rm & コンテナを削除する \\ \hline
-%    \end{tabular}
-%  \label{tb:ie-docker}
-%  \end{center}
-%\end{table}
-%
-%\subsection{digdog}
-%digdog は Kubernetes を利用したコンテナ貸出サービスである。
-%学生は Dockerfile を GitLab CI/CD を利用してビルドし, 学科の GitLab Container Registry に Docker イメージを登録する。
-%Web コンソールからコンテナ作成で使用するイメージは, 登録したイメージから選択することができる。
-%Kubernetes 上にコンテナを作成するため, 学生の入力を下に Deployment, Service, Ingress の作成を行う。
-%また, Namespace はユーザのアカウントID で作成され, Namespace ごとに RBAC の設定がされている。
-%そのため, 学生は手元の PC から Web コンソールから作成したコンテナを操作することができる。
-%表\ref{tb:digdog} は RBAC で許可されているリソースの操作である。\par
-%本研究のサービスは digdog を参考に実装されている。そのため, Kubernetes でのコンテナ作成は digdog と同じ流れで作成を行う。
-%だが, digdog では Docker Hub に登録されているイメージを選択することができない。
-%また, Kubernetes でのコンテナ貸出のため, Kubernetes クラスター上の Master が停止するとサービスを提供できないなどの課題があった。
-%本研究のサービスでは, Kubernetes でのコンテナの作成だけでなく, Docker でのコンテナの作成にも対応することで, Docker のみでサービスの提供ができるように改良を行った。
-%また, コンテナ作成時のイメージを選択ではなく入力にすることで, Docker Hub に登録されているイメージを利用できるように改良を行った。
-%
-%\begin{table}[htb]
-%  \begin{center}
-%  \caption{kubectl のコマンド}
-%  \begin{tabular}{c|l} \hline
-%    get  & Pod の一覧を表示する \\ \hline
-%    log & Pod の Log を表示する \\ \hline
-%    exec & Pod にアクセスする \\ \hline
-%    \end{tabular}
-%  \label{tb:digdog}
-%  \end{center}
-%\end{table}
-%
-%\subsection{クラウドサービス}
-%近年様々なクラウドサービスが普及し手元の PC から高性能なクラウド環境を利用することができる。
-%だが, クラウドサービスは無料から有料まであり。無料では時間制限や容量制限など様々な制限がある。
-%また有料だと設定のミスにより高額な請求がくるなど, 気軽に利用しづらい。
-%そのため, 本サービスはオンプレミス環境で実装を行った。
-%オンプレミス環境にすることで利用の制限がなく, サービスで使用するデータを自身で管理できるなどの良さがある。
-%だが, クラウドサービスと違い物理サーバなどのメンテナンスや, サービスの導入にあたって環境構築などの課題がある。
-%しかし, オンプレミスで運用していくことで, 学生の学習に繋がると考える。
-
 \section{今後の課題}
-本研究で実装したサービスでは学生が学習環境として利用するには, まだ必要な実装が不足している。\par
-本サービスでは, 大量のデータを用いる時に Singularity を使用できる環境を用意している。
-だが, Web コンソールから作成した Docker や Kubernetes のコンテナではデータの永続化に対応していないため, コンテナの削除で削除されてしまう。
-そこで, 学科のサーバでは学生ごとのディレクトリにマウントするなどの対策を行う必要がある。
+本研究で実装したサービスでは学生が学習環境として利用するには，まだ必要な実装が不足している。\par
+本サービスでは，大量のデータを用いる時に Singularity を使用できる環境を用意している。
+だが，Web コンソールから作成した Docker や Kubernetes のコンテナではデータの永続化に対応していないため，コンテナの削除で削除されてしまう。
+そこで，学科のサーバでは学生ごとのディレクトリにマウントするなどの対策を行う必要がある。
 \par
-本サービスでは, 学生が自由に Docker イメージを作成できる。また, Docker イメージを Singularity 用のイメージに変換する。
-そのため, イメージの容量でブレードサーバのストレージを圧迫してしまう可能性があることから, あまり利用されていないイメージは定期的に削除する必要がある。
+本サービスでは，学生が自由に Docker イメージを作成できる。また，Docker イメージを Singularity 用のイメージに変換する。
+そのため，イメージの容量でブレードサーバのストレージを圧迫してしまう可能性があることから，あまり利用されていないイメージは定期的に削除する必要がある。
 \par
 次にネットワークの設定である。
-作成したコンテナへのアクセスには, コンテナが動作しているサーバの IP アドレス, 設定されたポート番号を使用する。
-そのため, 外部からアクセスなどに対応することができない。そこで, コンテナごとに IP アドレスを設定するなどの対策が必要である。
+作成したコンテナへのアクセスには，コンテナが動作しているサーバの IP アドレス，設定されたポート番号を使用する。
+そのため，外部からアクセスなどに対応することができない。そこで，コンテナごとに IP アドレスを設定するなどの対策が必要である。
 \par
-また, 本サービスではユーザごとにリソースの制限を行っていないため, 過剰なリソースの占有を防ぐための対策をする必要がある。
+また，本サービスではユーザごとにリソースの制限を行っていないため，過剰なリソースの占有を防ぐための対策をする必要がある。
 GPU などの負荷がかかるプログラムの実行で使用されるリソースにはジョブ管理ソフトウェアなどで対策をとる。\
 
-%学科のブレードサーバでは学生ごとのディレクトリがある。
-%Docker ではそのディレクトリをコンテナ立ち上げ時にマウントすることで, コンテナ内のデータの永続化に対応できる。
-%また, Kubernetes では Peresistent Volumes という永続ボリュームの仕組みがある。この Peresistent Volumes をユーザごとに管理することで, コンテナ内のデータの永続化に対応できる。
-%このような対策でコンテナ内のデータの永続化に対応できるが, コンテナごとにデータの保存場所が違うなどの問題があるため, データを管理する仕組みが必要だと考える。\par
-%本サービスでは, 学生が自由に Docker イメージを作成できる。また, Docker イメージを Singularity 用のイメージに変換する。
-%そのため, イメージの容量でブレードサーバのストレージを圧迫してしまう可能性があることから, 定期的にイメージを削除する必要がある。
-%また, 本サービスではユーザごとにリソースの制限を行っていないため, 過剰なリソースの占有を防ぐための対策をする必要がある。
-%GPU などの負荷がかかるプログラムの実行で使用されるリソースにはジョブ管理ソフトウェアなどで対策をとる。\par
-%本サービスは Docker Hub に登録されている Dokcer イメージを利用できるが, Docker Hub は誰でもイメージを登録することができる。
-%そのため, Docker Hub に登録されているイメージにマルウェアが仕込まれている可能性がある。
-%イメージの取得時にスキャンを行うなど, セキュリティ対策を考える必要がある。
-
-%\section{まとめ}
-%本稿では, 本コースで利用する新規サービスの設計と実装, また本コースで利用しているサービスとの比較を行った。
-%学生がコンテナ技術を用いて学習環境を利用できるサービスの設計をし, マルチユーザ環境に対応した実装をすることができた。
-%学生は学科アカウントを持っていれば, Web コンソールからコンテナの作成ができる。
-%また, GitLab CI/CD を利用し Dockerfile から Docker イメージをビルドすることで, イメージの作成を学ぶこともできる。\par
-%今後, テスト環境にデプロイを行い, ユーザやシステム管理チームからのフィードバックをもらい, 改善や実証実験を目指す。
-
 \begin{thebibliography}{99}
 
-\bibitem{singu} Singularity, https://sylabs.io/singularity/, 2020/9/11.
-\bibitem{docker} Docker, https://www.docker.com/, 2020/9/11.
+\bibitem{singu} Singularity. https://sylabs.io/singularity/, 2020/9/11.
+\bibitem{docker} Docker, https://www.docker.com/. 2020/9/11.
 \bibitem{dockerhub} Docker Hub, https://hub.docker.com/, 2020/9/11.
 \bibitem{k8s} Kubernetes, https://kubernetes.io/, 2020/9/11.
 \bibitem{sdk} Docker Engine API, https://docs.docker.com/engine/api/, 2020/9/11.