Files
SSW590-DevOps/devopsHosts.tex
T

83 lines
4.5 KiB
TeX

\chapter{Hosts}
\ChapterLabel{Hosts}
\index{hosts}
\index{hosts!inventory}
\index{hosts!naming convention}
\index{development environment}
\index{Amazon EC2}
\section{Purpose}
This chapter names the hosts that will make up the development environment for
\CourseNumber\ and records the role, platform, and ownership of each. It is an
inventory of intent: no machine listed here has been provisioned, and the chapter therefore
presents no execution \gls{evidence}. It is expected to grow as later
assignments add services to the environment.
\section{Naming Convention}
\index{hosts!naming}
Each \gls{host} that is provisioned for this course is named
\texttt{ssw590-\textit{role}-\textit{nn}}, where \textit{role} identifies the
function the machine serves and \textit{nn} is a two-digit ordinal within that
role. Naming by role rather than by instance identifier keeps the name stable
if the underlying machine is replaced, and keeps the inventory readable when
more than one host serves the same purpose. Hosts that already exist
independently of this course retain their existing names.
\section{Host Inventory}
\index{hosts!table}
The \textbf{Status} column distinguishes machines already in use from those that
will be configured in a later assignment. A host is marked \emph{In service}
only once it exists and is reachable.
\begin{tabularx}{\linewidth}{L{3.0cm}YL{3.3cm}L{2.0cm}}
\caption{Planned Host Inventory\label{Table:HostInventory}}\\
\toprule \textbf{Host name} & \textbf{Role} & \textbf{Platform} & \textbf{Status}\\ \midrule
\endfirsthead
\multicolumn{4}{l}{\small\itshape Planned Host Inventory (continued)}\\
\toprule \textbf{Host name} & \textbf{Role} & \textbf{Platform} & \textbf{Status}\\ \midrule
\endhead \bottomrule \endlastfoot
\texttt{ssw590-dev-01} & Primary Linux host for the course. Target for service configuration, deployment exercises, and command-line work. & Ubuntu Server LTS on Amazon EC2 & Planned\\
\texttt{ssw590-build-01} & Build and integration host, kept separate from the deployment target so that a failed build cannot disturb a running service. To be provisioned only if a later assignment requires it. & Ubuntu Server LTS on Amazon EC2 & Conditional\\
\end{tabularx}
\section{Access and Ownership}
\index{hosts!access model}
\index{least privilege}
All hosts listed above are owned and administered by the author. The following
rules govern access to the Linux hosts once they are provisioned.
\begin{itemize}[leftmargin=*]
\item Interactive access is by \gls{ssh} public key only.
Password authentication is disabled in the server configuration.
The local account password recorded in \ChapterRef{Passwords} authenticates \texttt{sudo} only.
\item Inbound \gls{ssh} is restricted by source address to the workstation
listed above rather than opened to the public Internet.
\item Day-to-day work is performed by an unprivileged account. Administrative
rights are granted per command rather than by general membership in the
\texttt{sudo} group.
\item Should a teammate require access after teams are formalized, that person
receives a separate named account rather than a shared login, so that
access can be revoked individually and actions remain attributable.
\end{itemize}
\section{Cost and Cleanup}
\index{hosts!cost}
\index{hosts!teardown}
The Linux hosts are expected to run on the smallest instance size that supports
the coursework, under whatever free-tier or credit allowance the account
provides, with a billing alarm configured before the first instance is
launched. Compute is billed per instance-hour, and attached storage whether or
not the instance is running, so each additional host adds cost independently of
how heavily it is used: provisioning \texttt{ssw590-build-01} alongside
\texttt{ssw590-dev-01} would approximately double the compute cost of the
environment. It is therefore left unprovisioned until an assignment requires
builds to be isolated from the deployment target, and would be stopped between
uses rather than run continuously; only \texttt{ssw590-dev-01} needs to remain
available at all times.
Each planned host is disposable. Teardown consists of terminating the instance,
deleting the attached storage volume, and releasing any static address reserved
for it; a static address left reserved after the instance is gone continues to
be billed. Because the \gls{ami} and the configuration steps are recorded, a
terminated host can be rebuilt rather than preserved, which is why teardown is
treated as routine rather than exceptional.