%%
%% 研究報告用スイッチ
%% [techrep]
%%
%% 欧文表記無しのスイッチ(etitle,eabstractは任意)
%% [noauthor]
%%

%\documentclass[submit,techrep]{ipsj}
\documentclass[submit,techrep,noauthor]{ipsj}



\usepackage[dvips,dvipdfmx]{graphicx}
\usepackage{latexsym}
\usepackage{listings}
\lstset{
  language=C,
  tabsize=2,
  frame=single,
  basicstyle={\tt\footnotesize}, %
  identifierstyle={\footnotesize}, %
  commentstyle={\footnotesize\itshape}, %
  keywordstyle={\footnotesize\ttfamily}, %
  ndkeywordstyle={\footnotesize\ttfamily}, %
  stringstyle={\footnotesize\ttfamily},
  breaklines=true,
  captionpos=b,
  columns=[l]{fullflexible}, %
  xrightmargin=0zw, %
  xleftmargin=1zw, %
  aboveskip=1zw,
  numberstyle={\scriptsize}, %
  stepnumber=1,
  numbersep=0.5zw, %
  lineskip=-0.5ex,
}
\usepackage{caption}


\def\Underline{\setbox0\hbox\bgroup\let\\\endUnderline}
\def\endUnderline{\vphantom{y}\egroup\smash{\underline{\box0}}\\}
\def\|{\verb|}
%

%\setcounter{巻数}{59}%vol59=2018
%\setcounter{号数}{10}
%\setcounter{page}{1}
\renewcommand{\lstlistingname}{Code}

\begin{document}


\title{情報工学科演習用のコンテナ技術を用いた新規サービスの設計・実装}

%\etitle{How to Prepare Your Paper for IPSJ SIG Technical Report \\ (version 2018/10/29)}

\affiliate{KIE}{琉球大学大学院理工学研究科情報工学専攻}
\affiliate{IE}{琉球大学工学部工学科知能情報コース}


\author{宮平 賢}{Miyahira Ken}{IE}[mk@cr.ie.u-ryukyu.ac.jp]
\author{河野 真治}{Shinji Kono}{IE}[kono@ie.u-ryukyu.ac.jp]

\begin{abstract}
情報技術の普及に伴い情報系の学生が課題や演習を行う学習環境が必要である。
この学習環境では, 課題や演習によっては並列処理により, CPU より GPU が必要となる場合がある。
このような学習環境を複数の学生に提供する方法として, VM や コンテナがある。
しかし, 琉球大学工学部で運用している VM 貸出サービスでは, GPU を共有に対応していない。
そこで, コンテナを利用することができる Docker と Singularity を用いて, オンプレミス環境でコンテナ貸出サービスを提供する。
また, PC 上からコンテナへの操作を可能にするために Kubernetes でのコンテナ作成にも対応する。
コンテナ貸出サービスは LDAP で管理された学生のアカウントを使用することで, 適切にコンテナの管理を行う。
本稿ではサービスを実装する上で必要な技術概要を延べ, サービスの設計・実装を行う。
\end{abstract}

\maketitle

\section{はじめに}
情報通信技術の普及に伴い学生が学ぶ学習環境が必要となる。その学習環境として VM や コンテナにより, 手軽に開発し試せる技術が普及している。
だが, 手元の PC 上で VM や コンテナを立ち上げ, 開発を行うことはできるが, VM や コンテナの使用には高性能 PC や 有料のクラウドサービスが必要になる場合がある。
この大きな負担を学生に負わせない仕組みが必要である。
\par
琉球大学工学部工学科知能情報コースでは新たに人工知能やシステム開発などの先端技術を身につける講義や実験が設けられた。
講義の演習や実験は学生の PC で環境を構築し実行する。
本コースでは希望する学生に学科のブレードサーバから仮想環境を貸出すサービスを行なっている。
貸出をする VM のデフォルトのスペックは CPU 1コア, メモリ 1GB, ストレージ 10GB である。
デフォルトのスペックでは不足する場合, 要望に応じてスペックの変更を行なっている。
だが, 貸出 VM でも課題によってはスペックが足りなく, 処理に時間がかかることがあった。
例として, 人工知能の講義において課される課題においては CPU より GPU を用いることで処理時間を早くすることができる。
しかし, 現在の VM 貸出サービスでは GPU の共有に対応していない。
VM 上で GPU を共有するには PCI パススルーを利用することで可能だが, PCI パススルーでは複数の VM に共有することができない。
GPU が搭載されている PC は研究室によっては用意されているが, 研究室に所属していない学生は利用することができない。
そのため, 本コースの学生が高性能な環境を利用できる新たな仕組みが必要である。
\par
学科のブレードサーバに搭載される GPU は VM の貸出サービスでは利用することができない。そこでコンテナ技術を利用する。
コンテナ管理ソフトウェアである Docker\cite{docker} では NVIDIA Container Toolkit である nvidia-docker\cite{nvidia-docker} を利用することで, 複数のコンテナで GPU を共有することができる。
Docker は基本的に root 権限で動作する。また一般ユーザが docker コマンドを使用するには docker グループに追加する必要がある。
そのため Docker をマルチユーザ環境で使用すると, 他ユーザのコンテナを操作できるなどセキュリティ上の問題がある。\par
そこで, 本論文では, Docker とマルチユーザ環境で利用しやすいコンテナプラットフォームである Singularity\cite{singu} を利用したコンテナ貸出サービスを設計・実装する。
このコンテナ貸出サービスでは, Web コンソールからコンテナの管理をすることで他ユーザのコンテナへの操作をさせない。
%また, 本コースの類似サービスの課題であった外部リポジトリの利用は, Docker の機能を HTTP API で提供することで解消する。

\section{技術概要}
本研究で使用した仮想化技術, コンテナ技術, また本コースで利用しているサービスについての概要を説明する。

\subsection{Docker}
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}

\subsection{Singularity}
Singularity とは, HCP クラスタ上で複雑なアプリケーションを実行するために開発されたコンテナプラットフォームである。
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 CI/CD は 継続的インテグレーション(CI)・継続的デリバリー(CD)を GitLab から利用することができる。
CI では GitLab のコードを定期的または自動的にビルド・テストを行う。CD は CI を拡張した機能であり, ビルドやテストだけでなくリリースの準備も行う。
%本コースでは, Operating System という講義で Mercurial と Jenkins を利用してコードのテストを行う課題などがある。
\par
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 とは Kubernetes を利用し Web コンソールからコンテナを作成することができるコンテナ貸出サービスである。
学生は学科アカウントを使用して Web サービスへログインし, 登録されている Docker イメージでコンテナを作成することができる。

\section{サービスの設計}
サービスでは本コースの学生や教員がにコンテナ貸出を行う。このコンテナ貸出の構成を図\ref{fig:wm} に示し, 概要を以下で説明する。

\subsection{コンテナの作成}
学生または教員は学科アカウントで Web コンソールへログインする。Web コンソールでは ユーザのコンテナ一覧や Docker イメージ一覧を確認することができる。
コンテナ作成は Docker コンテナと Kubernetes コンテナの 2つから選択することができる。
コンテナ作成を選択するとコンテナを作成するために必要な情報を入力する。入力する内容は表\ref{tb:wmcon} である。
コンテナ名にはユーザのアカウント名が補完されるため, 他のユーザと被ることはない。
Docker イメージには Docker Hub に登録されているイメージや, ユーザが作成したイメージを入力することができる。
環境変数とゲストポートはスペース区切りで複数入力することができる。
また, コンテナ内で GPU を使用するにはチェックボックスにチェックを入れる。
ホストポートは, エフェメラルポートの範囲から設定される。ユーザは設定されたホストポートを使用してコンテナのサービスへアクセスする。
また, ユーザは Docker コンテナに対しては Web コンソールから, Kubernetes コンテナには手元の PC から操作することができる。
必要なくなったコンテナは Web コンソールのコンテナ一覧から削除することができる。

\begin{table}[htb]
  \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 機能を利用する。
ユーザは学科 GitLab から CI トークンを取得し, Web コンソールに取得したトークンをセットする。この時 Docker 側に GitLab Runner の立ち上げを依頼する。
トークンの設定後, Web コンソールから CI 用の YAML ファイルをダウンロードし Dockerfile と一緒に学科 GitLab のリポジトリにプッシュする。
Docker イメージのビルドが成功すると Web コンソールのイメージ一覧で確認ができる。作成した Docker イメージは編集からイメージの使い方の記述や他の学生に共有するか設定を行える。
必要なくなったイメージは Web コンソールのイメージ一覧から削除することができる。

\subsection{Singularity の利用}
コンテナに大量のデータを送信する必要がある場合や, データを永続化させたい場合に Singularity を利用する。
Singularity は Docker イメージを変換し使用できるが, イメージの変換には sudo 権限が必要となる。
Docker イメージの変換を申請性にすると, 管理者の仕事が増え, またユーザも利用しづらい。
Singularity はユーザ権限で動作することから, 学生が ssh でブレードサーバへ接続し利用する方が適している。
そこで, Web コンソールから Singularity 用のイメージをダウンロードできる仕様とする。\par
ユーザは利用したいイメージをダウンロードし, ブレードサーバへ送信して Singularity を使用する。Singularity を利用する流れを図\ref{fig:singu} に示す。

\begin{figure*}[tb]
    \begin{center}
        \includegraphics[width=100mm]{Images/whalemountain.pdf}
    \end{center}
    \caption{システム構成}
    \label{fig:wm}
\end{figure*}

\begin{figure}[tb]
    \begin{center}
        \includegraphics[width=80mm]{Images/singularity.pdf}
    \end{center}
    \caption{Singularityの利用}
    \label{fig:singu}
\end{figure}

\section{サービスの実装}
本コースでは学科システムを教員の指導の下, 学生主体でシステム管理チームと呼ばれる組織によって構築・運用・管理が行われている。
学科システムはブレードサーバを 4 台, SAN 用ストレージと汎用ストレージをそれぞれ 2台ずつ導入している。本コースの基幹サービスはこのブレードサーバの仮想環境上で VM として動作している。
新たにサービスを実装するとなると, システム管理チームが運用・管理を行いやすい実装にする必要がある。\par
Web コンソールや Docker の操作を 1 つにまとめると, Docker コンテナの作成が 1台のブレードサーバのみになってしまう。
そこで, コンテナ貸出システムは, 機能ごとに以下の 3 つにサービスに分ける。
Docker や Kubernetes の操作を HTTP API で提供することにより, リクエスト先を変更することで複数のブレードサーバにコンテナを分散することができる。
だが, 現時点では未実装である。\par
実装にはDocker や Kubernetes の実装言語であり, 操作するためのライブラリが揃っている Go 言語を使用する。
\begin{itemize}
  \item Web コンソール
  \item Docker の操作
  \item Kubernetes の操作
\end{itemize}

%\begin{figure}[tb]
%    \begin{center}
%        \includegraphics[width=80mm]{Images/apihukusu.pdf}
%    \end{center}
%    \caption{機能の分散}
%    \label{fig:api}
%\end{figure}

\subsection{Web コンソール}
Web コンソールは本コースの学生や教員が利用するため, 学科アカウントでログインできる必要がある。学科の LDAP サーバを利用して学科アカウントで LDAP 認証を実装する。\par
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 の必要となる操作は以下である。
\begin{itemize}
  \item コンテナの作成
  \item コンテナの削除
  \item コンテナでのコマンド実行
  \item コンテナへファイル送信
  \item イメージ一覧の取得
  \item イメージの削除
\end{itemize}

コンテナは, 表\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

\subsection{Kubernetes の操作}
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 コンソールからコマンドの実行やファイルの送信などの操作を行わず, Role と RoleBinding を用いた Role-based access control (RBAC) 
を利用することで手元の PC より操作を行うこととする。
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{サービスの評価}

\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 のコンテナでは
データの永続化が対応していないため, コンテナの削除時に共に削除されてしまう。学科のブレードサーバでは学生ごとのディレクトリがある。
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
今後, テスト環境にデプロイを行い, ユーザやシステム管理チームからのフィードバックをもらい, 改善や実証実験を目指す。

\nocite{*}
\bibliographystyle{ipsjunsrt}
\bibliography{mk-wm}

\end{document}