diff --git a/docs/assets/images/userguides/geddes/Geddes-web-server-1.png b/docs/assets/images/userguides/geddes/Geddes-web-server-1.png new file mode 100644 index 00000000..f41e8aa1 Binary files /dev/null and b/docs/assets/images/userguides/geddes/Geddes-web-server-1.png differ diff --git a/docs/assets/images/userguides/geddes/Geddes-web-server-2.png b/docs/assets/images/userguides/geddes/Geddes-web-server-2.png new file mode 100644 index 00000000..1541cd11 Binary files /dev/null and b/docs/assets/images/userguides/geddes/Geddes-web-server-2.png differ diff --git a/docs/assets/images/userguides/geddes/Geddes-web-server-3.png b/docs/assets/images/userguides/geddes/Geddes-web-server-3.png new file mode 100644 index 00000000..78495fdb Binary files /dev/null and b/docs/assets/images/userguides/geddes/Geddes-web-server-3.png differ diff --git a/docs/assets/images/userguides/geddes/Geddes-web-server-4.png b/docs/assets/images/userguides/geddes/Geddes-web-server-4.png new file mode 100644 index 00000000..d5dc92dd Binary files /dev/null and b/docs/assets/images/userguides/geddes/Geddes-web-server-4.png differ diff --git a/docs/assets/images/userguides/geddes/Geddes-web-server-5.png b/docs/assets/images/userguides/geddes/Geddes-web-server-5.png new file mode 100644 index 00000000..264da4ec Binary files /dev/null and b/docs/assets/images/userguides/geddes/Geddes-web-server-5.png differ diff --git a/docs/assets/images/userguides/geddes/Geddes-web-server-6.png b/docs/assets/images/userguides/geddes/Geddes-web-server-6.png new file mode 100644 index 00000000..4589c2e9 Binary files /dev/null and b/docs/assets/images/userguides/geddes/Geddes-web-server-6.png differ diff --git a/docs/assets/images/userguides/geddes/Geddes-web-server-6b.png b/docs/assets/images/userguides/geddes/Geddes-web-server-6b.png new file mode 100644 index 00000000..62fc4bb9 Binary files /dev/null and b/docs/assets/images/userguides/geddes/Geddes-web-server-6b.png differ diff --git a/docs/assets/images/userguides/geddes/Geddes-web-server-7.png b/docs/assets/images/userguides/geddes/Geddes-web-server-7.png new file mode 100644 index 00000000..01a248b5 Binary files /dev/null and b/docs/assets/images/userguides/geddes/Geddes-web-server-7.png differ diff --git a/docs/assets/images/userguides/geddes/Geddes-web-server-8.png b/docs/assets/images/userguides/geddes/Geddes-web-server-8.png new file mode 100644 index 00000000..6dd6006d Binary files /dev/null and b/docs/assets/images/userguides/geddes/Geddes-web-server-8.png differ diff --git a/docs/assets/images/userguides/geddes/Geddes-web-server-9.png b/docs/assets/images/userguides/geddes/Geddes-web-server-9.png new file mode 100644 index 00000000..4bed1fff Binary files /dev/null and b/docs/assets/images/userguides/geddes/Geddes-web-server-9.png differ diff --git a/docs/assets/images/userguides/geddes/bio_geddes.jpeg b/docs/assets/images/userguides/geddes/bio_geddes.jpeg new file mode 100644 index 00000000..6ee653c7 Binary files /dev/null and b/docs/assets/images/userguides/geddes/bio_geddes.jpeg differ diff --git a/docs/assets/images/userguides/geddes/pod-debugging-1.png b/docs/assets/images/userguides/geddes/pod-debugging-1.png new file mode 100644 index 00000000..c21d863a Binary files /dev/null and b/docs/assets/images/userguides/geddes/pod-debugging-1.png differ diff --git a/docs/assets/images/userguides/geddes/pod-debugging-2.png b/docs/assets/images/userguides/geddes/pod-debugging-2.png new file mode 100644 index 00000000..5c3aea89 Binary files /dev/null and b/docs/assets/images/userguides/geddes/pod-debugging-2.png differ diff --git a/docs/userguides/geddes/access.md b/docs/userguides/geddes/access.md new file mode 100644 index 00000000..54a6e32b --- /dev/null +++ b/docs/userguides/geddes/access.md @@ -0,0 +1,47 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Access + +Access to the Geddes Composable Platform is handled via the RCAC web portal. When access is purchased, a Rancher project with your research group's name will be created and managers will be able to click to give users access, similar to how access is managed for community clusters. Links to access Geddes via the Rancher UI and the command line (`kubectl`) are below. + +## Rancher + +### Logging in to Rancher + +To access the Geddes user interface, you must be on a Purdue campus network or connected through [VPN](https://it.purdue.edu/services/vpn.php). + +Once connected to a Purdue network, the Geddes Rancher interface can be accessed via a web browser at [geddes.rcac.purdue.edu](https://geddes.rcac.purdue.edu). Log in by choosing "log in with shibboleth" and using Purdue Login at the login screen. + +## Kubectl + +### Configuring local kubectl access with a Kubeconfig file + +**kubectl** can be installed and run on your local machine to perform various actions against the Kubernetes cluster using the API server. + +These tools authenticate to Kubernetes using information stored in a [**kubeconfig**](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file. + +!!! note + A file that is used to configure access to a cluster is sometimes called a *kubeconfig* file. This is a generic way of referring to configuration files. It does not mean that there is a file named **kubeconfig**. + +To begin accessing Geddes via **kubectl** you must first gather your rancher generated **Kubeconfig** file and set up your local `.kube` directory. + +1. From anywhere in the Rancher UI navigate to the top right and click on either **Download KubeConfig** or **Copy KubeConfig to Clipboard** + * Create a directory in your home directory (`$HOME`) called `.kube` + * Change into the newly created directory and copy the file or contents of **KubeConfig** from earlier into a file called **config** +2. Test connections to the Geddes cluster + * To look at the current config settings we just set use `kubectl config view` + * Now let’s list the available resource types present in the API with `kubectl api-resources` + +To see more options of kubectl, review the [Kubernetes' kubectl cheatsheet](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). + +### Accessing kubectl in the Rancher web UI + +You can launch a kubectl command window from within the Rancher UI by selecting the **Kubectl Shell** button at the top right or using the hotkey (`` CTRL + ` ``). This will deploy a container in the cluster with kubectl installed and give you an interactive window to use the command from. diff --git a/docs/userguides/geddes/biography.md b/docs/userguides/geddes/biography.md new file mode 100644 index 00000000..6c1d5e13 --- /dev/null +++ b/docs/userguides/geddes/biography.md @@ -0,0 +1,28 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Biography of Lanelle Geddes +![Portrait of Lanelle Geddes](/assets/images/userguides/geddes/bio_geddes.jpeg){ align=right width="260" } + +LaNelle E. (Nerger) Geddes was born on September 15, 1935 in Houston, Texas to Carl O. and Evelyn Nerger. She received a B.S. in Nursing from the University of Houston in 1957, and earned a PhD in Biophysics there in 1970. After receiving her PhD, Geddes taught at the Texas Women's University and in the Department of Physiology at Baylor College of Medicine in Houston. + +Geddes joined the faculty at Purdue in 1975 where her husband, Leslie A. Geddes, was the head of the Department of Biomedical Engineering. Lanelle started in the School of Nursing as the Assistant Head of the Department. In 1980, she was promoted to the Head of the Department and served as Head until 1991. While at Purdue, Geddes challenged traditional perceptions of nurses as merely doctors' assistants who were wrongly believed to have no expertise or skill for diagnosis and treatment. In addition, Geddes was also instrumental in instituting a four-year nursing baccalaureate program and starting the Freshman Scholars, a program that provided scholarships to outstanding incoming freshman. + +Geddes' research was focused on cardiovascular physiology. Her teaching emphasized the impact of human pathophysiologic alterations and their influence on nursing and medical care. Her inclusion of pathophysiology encouraged her students to make better clinical judgments and to be stronger patient advocates. From 1996-2003, Geddes also taught pathophysiology to IU School of Medicine students at Purdue University. Geddes retired as a professor emeritus in 2003. + +Geddes' research and teaching had far-reaching impacts, and she received many awards over the course of her career. She was an AMOCO Foundation (Murphy) Award winner, a fellow of the University Teaching Academy, and a Helen B Schleman Gold Medallion Awardee. She also received the Lafayette YWCA Salute to Women Award and the Westminster Village Lifetime Service Award for her work within the community. Geddes passed away on January 25, 2016. + +## Citations + +Archives and Special Collections. (2021, May 19). Geddes, Lanelle E., September 15, 1935 - January 25, 2016. Purdue University. Retrieved from: + + + +[**Back to Geddes User Guide**](index.md) diff --git a/docs/userguides/geddes/concepts.md b/docs/userguides/geddes/concepts.md new file mode 100644 index 00000000..d2332d69 --- /dev/null +++ b/docs/userguides/geddes/concepts.md @@ -0,0 +1,56 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Concepts + +## Containers & Images + +**Image** - An image is a simple text file that defines the source code of an application you want to run as well as the libraries, dependencies, and tools required for the successful execution of the application. Images are immutable meaning they do not hold state or application data. Images represent a software environment at a specific point of time and provide an easy way to share applications across various environments. Images can be built from scratch or downloaded from various repositories on the internet, additionally many software vendors are now providing containers alongside traditional installation packages like Windows .exe and Linux rpm/deb. + +**Container** - A container is the run-time environment constructed from an image when it is executed or run in a container runtime. Containers allow the user to attach various resources such as network and volumes in order to move and store data. Containers are similar to virtual machines in that they can be attached to when a process is running and have arbitrary commands executed that affect the running instance. However, unlike virtual machines, containers are more lightweight and portable allowing for easy sharing and collaboration as they run identically in all environments. + +**Tags** - Tags are a way of organizing similar image files together for ease of use. You might see several versions of an image represented using various tags. For example, we might be building a new container to serve web pages using our favorite web server: nginx. If we search for the nginx container on Docker Hub image repository we see many options or tags are available for the official nginx container. + +The most common you will see are typically `:latest` and `:number` where *number* refers to the most recent few versions of the software releases. In this example we can see several tags refer to the same image: `1.21.1, mainline, 1, 1.21,` and `latest` all reference the same image while the `1.20.1, stable, 1.20` tags all reference a common but different image. In this case we likely want the nginx image with either the `latest` or `1.21.1` tag represented as `nginx:latest` and `nginx:1.21.1` respectively. + +**Container Security** - Containers enable fast developer velocity and ease compatibility through great portability, but the speed and ease of use come at some costs. In particular it is important that folks utilizing container driver development practices have a well established plan on how to approach container and environment security. + +**Container Registries** - Container registries act as large repositories of images, containers, tools and surrounding software to enable easy use of pre-made containers software bundles. Container registries can be public or private and several can be used together for projects. Docker Hub is one of the largest public repositories available, and you will find many official software images present on it. You need a user account to avoid being rate limited by Docker Hub. A private container registry based on Harbor is available to use; see the [Container Registry](registry.md) page. + +**Docker Hub** - Docker Hub is one of the largest container image registries that exists and is well known and widely used in the container community, it serves as an official location of many popular software container images. Container image repositories serve as a way to facilitate sharing of pre-made container images that are “ready for use.” Be careful to always pay attention to who is publishing particular images and verify that you are utilizing containers built only from reliable sources. + +**Harbor** - Harbor is an open source registry for Kubernetes artifacts, it provides private image storage and enforces container security by vulnerability scanning as well as providing RBAC or role based access control to assist with user permissions. Harbor is a registry similar to Docker Hub, however it gives users the ability to create private repositories. You can use this to store your private images as well as keeping copies of common resources like base OS images from Docker Hub and ensure your containers are reasonably secure from common known vulnerabilities. + +## Container Runtime Concepts + +**Docker Desktop** - Docker Desktop is an application for your Mac / Windows machine that will allow you to build and run containers on your local computer. Docker desktop serves as a container environment and enables much of the functionality of containers on whatever machine you are currently using. This allows for great flexibility, you can develop and test containers directly on your laptop and deploy them directly with little to no modifications. + +**Volumes** - Volumes provide us with a method to create persistent data that is generated and consumed by one or more containers. For docker this might be a folder on your laptop while on a large Kubernetes cluster this might be many SSD drives and spinning disk trays. Any data that is collected and manipulated by a container that we want to keep between container restarts needs to be written to a volume in order to remain around and be available for later use. + +## Container Orchestration Concepts + +**Container Orchestration** - Container orchestration broadly means the automation of much of the lifecycle management procedures surrounding the usage of containers. Specifically it refers to the software being used to manage those procedures. As containers have seen mass adoption and development in the last decade, they are now being used to power massive environments and several options have emerged to manage the lifecycle of containers. One of the industry leading options is Kubernetes, a software project that has descended from a container orchestrator at Google that was open sourced in 2015. + +**Kubernetes (K8s)** - Kubernetes (often abbreviated as "K8s") is a platform providing container orchestration functionality. It was open sourced by Google around a decade ago and has seen widespread adoption and development in the ensuing years. K8s is the software that provides the core functionality of the Geddes Composable Platform by managing the complete lifecycle of containers. Additionally it provides the following functions: service discovery and load balancing, storage orchestration, secret and configuration management. The Kubernetes cluster can be accessed via the Rancher UI or the kubectl command line tool. + +**Rancher** - Rancher is a “complete software stack for teams adopting containers” as described by its website. It can be thought of as a wrapper around Kubernetes, providing an additional set of tools to help operate the K8s cluster efficiently and additional functionality that does not exist in Kubernetes itself. Two examples of the added functionality is the Rancher UI that provides an easy to use GUI interface in a browser and Rancher projects, a concept that allows for multi-tenancy within the cluster. Users can interact directly with Rancher using either the Rancher UI or Rancher CLI to deploy and manage workloads on the Geddes Composable Platform. + +**Rancher UI** - The Rancher UI is a web based graphical interface to use the Geddes Composable Platform from anywhere. + +**Rancher CLI** - The Rancher CLI provides a convenient text based toolkit to interact with the cluster. The binary can be downloaded from the link on the right hand side of the footer in the Rancher UI. After you download the Rancher CLI, you need to make a few configurations Rancher CLI requires: + +- Your Rancher Server URL, which is used to connect to Rancher Server. +- An API Bearer Token, which is used to authenticate with Rancher. See Creating an API Key. + +After setting up the Rancher CLI you can issue `rancher --help` to view the full range of options available. + +**Kubectl** - Kubectl is a text based tool for working with the underlying Geddes Kubernetes cluster. In order to take advantage of kubectl you will either need to set up a Kubeconfig File or use the built in kubectl shell in the Rancher UI. You can learn more about kubectl and how to download the kubectl file on the [Kubectl](access.md#kubectl) page. + +**Storage** - Storage is utilized to provide persistent data storage between container deployments. The **Ceph** filesystem provides access to Block, Object and shared file systems. File storage provides an interface to access data in a file and folder hierarchy similar to NTFS or NFS. Block storage is a flexible type of storage that allows for snapshotting and is good for database workloads and generic container storage. Object storage is also provided by Ceph, this features a REST based bucket file system providing S3 and Swift compatibility. diff --git a/docs/userguides/geddes/examples/database.md b/docs/userguides/geddes/examples/database.md new file mode 100644 index 00000000..1d6aeaba --- /dev/null +++ b/docs/userguides/geddes/examples/database.md @@ -0,0 +1,75 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Database + +## Deploy a postgis Database + +1. Select your **Project** from the top right dropdown +2. Using the far left menu, select **Workload** +3. Click **Create** at the top right +4. Select the appropriate **Deployment Type** for your use case, here we will select and use **Deployment** +5. Fill out the form + * Select **Namespace** + * Give an arbitrary **Name** + * Set **Container Image** to the postgis Docker image: `geddes-registry.rcac.purdue.edu/docker-hub-cache/postgis/postgis:latest` + * Set the postgres user password + + Select the **Add Variable** button under the **Environment Variables** section + + Fill in the fields **Variable Name** and **Value** so that we have a variable `POSTGRES_PASSWORD = ` + * Create a persistent volume for your database + + Select the **Storage** tab from within the current form on the left hand side + + Select **Add Volume** and choose **Create Persistent Volume Claim** + + Give an arbitrary **Name** + + Select **Single-Node Read/Write** + + Select an appropriate **Storage Class** from the dropdown and give **Capacity** in GiB **e.g** 5 + + Provide the default postgres data directory as a **Mount Point** for the persistent volume `/var/lib/postgresql/data` + + Set **Sub Path** to `data` + * Set resource CPU limitations + + Select **Resources** tab on the left within the current form + + Under the **CPU Reservation** box fill in `2000`. This ensures that Kubernetes will only schedule your workload to nodes that have that resource amount available, guaranteeing your application has 2 CPU cores to utilize + + Under the **CPU Limit** box also fill in `2000`. This ensures that your workload cannot exceed or utilize more than 2 CPU cores. This helps resource quota management on the project level. + * Setup Pod Label + + Select **Labels & Annotations** on the left side of the current form + + Select **Add Label** under the **Pod Labels** section + + Give an arbitrary unique key and value you can remember later when creating Services and other resources **e.g** **Key:** `my-db` **Value:** `postgis` + * Select **Create** to launch the postgis database + +Wait a couple minutes while your persistent volume is created and the postgis container is deployed. The "does not have minimum availability" message is expected. But, waiting more than 5 minutes for your workload to deploy typically indicates a problem. You can check for errors by clicking your workload name (i.e. "mydb"), then the lower button on the right side of your deployed pod and selecting **View Logs**. If all goes well, you will see an Active status for your deployment. + +## Expose the Database to external clients + +Use a **LoadBalancer** service to automatically assign an IP address on a private Purdue network and open the postgres port (5432). A DNS name will automatically be configured for your service as `..geddes.rcac.purdue.edu`. + +1. Using the far left menu navigate to **Service Discovery** > **Services** +2. Select **Create** at the top right +3. Select **Load Balancer** +4. Fill out the form + * Ensure to select the **namespace** where you deployed the postgis database + * Give a **Name** to your **Service**. Remember that your final DNS name when the service creates will be in the format of `..geddes.rcac.purdue.edu` + * Fill in **Listening Port** and **Target Port** with the postgis default port **5432** + * Select the **Selectors** tab within the current form + + Fill in **Key** and **Value** with the label values you created during the **Setup Pod Label** step from earlier **e.g** **Key:** `my-db` **Value:** `postgis` + + IMPORTANT: The yellow bar will turn green if your key-value pair matches the pod label you set during the "Setup Pod Label" deployment step above. If you don't see a green bar with a matching Pod, your LoadBalancer will not work. + * Select the **Labels & Annotations** tab within the current form + + Select **Add Annotation** + + To deploy to a **Purdue Private Address Range** fill in **Key:** `metallb.universe.tf/address-pool` **Value:** `geddes-private-pool` + + To deploy to a **Public Address Range** fill in **Key:** `metallb.universe.tf/address-pool` **Value:** `geddes-public-pool` + +Kubernetes will now automatically assign you an IP address from the Geddes private IP pool. You can check the IP address by hovering over the "5432/tcp" link on the Service Discovery page or by viewing your service via kubectl on a terminal. + +``` +$ kubectl -n get services +``` + +Verify your DNS record was created: + +``` +$ host ..geddes.rcac.purdue.edu +``` diff --git a/docs/userguides/geddes/examples/index.md b/docs/userguides/geddes/examples/index.md new file mode 100644 index 00000000..8da55c8c --- /dev/null +++ b/docs/userguides/geddes/examples/index.md @@ -0,0 +1,17 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Examples + +Examples of deploying a database with persistent storage and making it available on the network and deploying a webserver using a self-assigned URL. + +- [**Database**](database.md) +- [**Web Server**](webserver.md) +- [**R Shiny**](r-shiny.md) \ No newline at end of file diff --git a/docs/userguides/geddes/examples/r-shiny.md b/docs/userguides/geddes/examples/r-shiny.md new file mode 100644 index 00000000..9ec64c74 --- /dev/null +++ b/docs/userguides/geddes/examples/r-shiny.md @@ -0,0 +1,79 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# R Shiny + +This guide provides instructions on how to build a Docker image for an R Shiny application, push it to the Geddes Registry and deploy it on Geddes. + +## Create an R Shiny Docker Image + +Create a local Dockerfile by saving the following Dockerfile to your computer and editing the contents for your R Shiny App. + +``` +FROM rocker/shiny + +# install R package dependencies +RUN apt-get update && apt-get install -y \ + libssl-dev \ + git \ + ## clean up + && apt-get clean \ + && rm -rf /var/lib/apt/lists/ \ + && rm -rf /tmp/downloaded_packages/ /tmp/*.rds + +## Install any R packages you need +RUN install2.r --error \ + \ + \ + \ + ## clean up + && rm -rf /tmp/downloaded_packages/ /tmp/*.rds + +## copy shiny app to shiny server location +COPY ./ /srv/shiny-server/ +``` + +## Docker Build and Testing Process + +Build the Docker image locally based on the Dockerfile above. The Dockerfile must be in your current working directory. This command tags the image with the name "myshinyapp" and version 1.0. + +```bash +docker build -t myshinyapp:1.0 . +``` + +Test your application locally. This command will run your container locally and expose the R Shiny port (3838) so it can be accessed via `http://localhost:3838` in your web browser. + +On Linux or Mac: `docker run --network=host myshinyapp:1.0` + +On Windows: `docker run -p 3838:3838 myshinyapp:1.0` + +Iterate on code changes locally until you want to deploy on Geddes. + +## Tag and Upload to the Geddes Registry + +Tag the image for upload to the Geddes Registry. + +```bash +docker tag myshinyapp:1.0 geddes-registry.rcac.purdue.edu//myshinyapp:1.0 +``` + +Push the image to the Geddes Registry. Run the login command using your Purdue career account username and password if you currently are not authenticated to the registry. + +```bash +docker login geddes-registry.rcac.purdue.edu +``` + +```bash +docker push geddes-registry.rcac.purdue.edu//myshinyapp:1.0 +``` + +## Deploy the Application on Geddes + +To deploy the application, one can follow the [instructions for deploying a web server](webserver.md) and replace the image name with the Geddes registry image tag from above: `geddes-registry.rcac.purdue.edu//myshinyapp:1.0` diff --git a/docs/userguides/geddes/examples/webserver.md b/docs/userguides/geddes/examples/webserver.md new file mode 100644 index 00000000..eb72562a --- /dev/null +++ b/docs/userguides/geddes/examples/webserver.md @@ -0,0 +1,56 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Web Server + +## Nginx Deployment + +1. Select your **Project** from the top right dropdown + ![Geddes Web Server 1](/assets/images/userguides/geddes/Geddes-web-server-1.png) +2. Using the far left menu, select **Workload** +3. Click **Create** at the top right + ![Geddes Web Server 2](/assets/images/userguides/geddes/Geddes-web-server-2.png) +4. Select the appropriate **Deployment Type** for your use case, here we will select and use **Deployment** + ![Geddes Web Server 3](/assets/images/userguides/geddes/Geddes-web-server-3.png) +5. Fill out the form + * Select **Namespace** + * Give an arbitrary **Name** + * Set **Container Image** to the nginx Docker image: `geddes-registry.rcac.purdue.edu/docker-hub-cache/library/nginx` + ![Geddes Web Server 4](/assets/images/userguides/geddes/Geddes-web-server-4.png) + * Create a **Cluster IP** service to point our external accessible ingress to later + + Click **Add Port** + + Click **Service Type** and with the dropdown select **Cluster IP** + + In the **Private Container Port** box type **80** + ![Geddes Web Server 5](/assets/images/userguides/geddes/Geddes-web-server-5.png) + * Setup Pod Label + + Select **Labels & Annotations** on the left side of the current form + + Select **Add Label** under the **Pod Labels** section + + Give an arbitrary unique key and value you can remember later when creating Services and other resources **e.g** **Key:** `my-web` **Value:** `nginx` + ![Geddes Web Server 6](/assets/images/userguides/geddes/Geddes-web-server-6.png) + ![Geddes Web Server 6b](/assets/images/userguides/geddes/Geddes-web-server-6b.png) + * Click **Create** + +Wait a couple minutes while your application is deployed. The "does not have minimum availability" message is expected. But, waiting more than 5 minutes for your workload to deploy typically indicates a problem. You can check for errors by clicking your workload name (i.e. "mywebserver"), then using the vertical ellipsis on the right hand side of your deployed pod and selecting **View Logs**. + +If all goes well, you will see an Active status for your deployment. + +## Expose the web server to external clients via an Ingress + +1. Using the far left menu navigate to **Service Discovery** > **Ingresses** and select **Create** at the top right + ![Geddes Web Server 7](/assets/images/userguides/geddes/Geddes-web-server-7.png) +2. Fill out the form + * Ensure to select the **namespace** where you deployed the nginx + * Give an arbitrary **Name** + * Under **Request Host** give the url you want for your web application **e.g** `my-nginx.geddes.rcac.purdue.edu` + * Fill in the value **Path** > **Prefix** as `/` + * Use the **Target Service** and **Port** dropdowns to select the service you created during the **Nginx Deployment** section + ![Geddes Web Server 8](/assets/images/userguides/geddes/Geddes-web-server-8.png) + * The default Ingress is **private**, which is only accessible within the Purdue network. To make a **public** one, change the **Ingress Class** to `public`: + ![Geddes Web Server 9](/assets/images/userguides/geddes/Geddes-web-server-9.png) \ No newline at end of file diff --git a/docs/userguides/geddes/index.md b/docs/userguides/geddes/index.md new file mode 100644 index 00000000..bdc59f95 --- /dev/null +++ b/docs/userguides/geddes/index.md @@ -0,0 +1,24 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Geddes User Guide + +New usage patterns have emerged in research computing that depend on the availability of custom services such as notebooks, databases, elastic software stacks, and science gateways alongside traditional batch HPC. The Geddes Composable Platform is a [Kubernetes](https://kubernetes.io/) based private cloud managed with [Rancher](https://rancher.com) that provides a platform for creating composable infrastructure on demand. This cloud-style flexibility provides researchers the ability to self-deploy and manage persistent services to complement HPC workflows and run container-based data analysis tools and applications. Funded by the National Science Foundation under grant OAC-2018926, Geddes consists of Dell compute nodes with two 64-core AMD Epyc 'Rome' processors (128 cores per node). + +- [**Overview of Geddes**](overview.md) +- [**Biography of Lanelle Geddes**](biography.md) +- [**Concepts**](concepts.md) +- [**Access**](access.md) +- [**Registry**](registry.md) +- [**Workloads**](workloads.md) +- [**Services**](services.md) +- [**Storage**](storage.md) +- [**Examples**](examples/index.md) +- [**Troubleshooting**](troubleshooting.md) diff --git a/docs/userguides/geddes/overview.md b/docs/userguides/geddes/overview.md new file mode 100644 index 00000000..2f24b67c --- /dev/null +++ b/docs/userguides/geddes/overview.md @@ -0,0 +1,44 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Overview of Geddes + +Geddes is a Community Composable Platform optimized for composable, cloud-like workflows that are complementary to the batch applications run on Community Clusters. Funded by the National Science Foundation under grant OAC-2018926, Geddes consists of Dell Compute nodes with two 64-core AMD Epyc 'Rome' processors (128 cores per node). + +To purchase access to Geddes today, go to the [Cluster Access Purchase](https://www.rcac.purdue.edu/purchase) page. Please subscribe to our Community Cluster Program Mailing List to stay informed on the latest purchasing developments or [contact us](mailto:rcac-cluster-purchase@lists.purdue.edu) if you have any questions. + +## Geddes Namesake + +Geddes is named in honor of Lanelle Geddes, a Purdue professor and Head of the School of Nursing. More information about her life and impact on Purdue is available in a [Biography of Lanelle Geddes](biography.md). + +## Geddes Specifications + +All Geddes compute nodes have 128 processor cores and 100 Gbps Infiniband interconnects. + +### Geddes Hyperconverged Worker Nodes + +| Worker Type | Number of Nodes | Processors per Node | Cores per Node | Storage per Node | Memory per Node | +| --- | --- | --- | --- | --- | --- | +| A | 8 | Two AMD Epyc CPUs @ 2.0GHz | 128 | 24 TB SATA SSD | 1 TB | +| B | 16 | Two AMD Epyc CPUs @ 2.0GHz | 128 | 24 TB SATA SSD | 512 GB | + +### Geddes Hyperconverged GPU Nodes + +| Number of Nodes | Processors per Node | Cores per Node | GPUs per Node | Storage per Node | Memory per Node | +| --- | --- | --- | --- | --- | --- | +| 4 | Two AMD Epyc CPUs @ 2.0GHz | 128 | 2 Nvidia A100 | 24 TB SATA SSD | 512 GB | + +### Geddes Storage Nodes + +| Number of Nodes | Processors per Node | Cores per Node | Storage per Node | Memory per Node | +| --- | --- | --- | --- | --- | +| 8 | Two Intel Xeon Gold 6126 | 24 | 24 TB NVMe | 192 GB | + +Geddes nodes run Rocky 8 and use Rancher and Kubernetes as the resource manager for resource and workload orchestration. diff --git a/docs/userguides/geddes/registry.md b/docs/userguides/geddes/registry.md new file mode 100644 index 00000000..3f322e97 --- /dev/null +++ b/docs/userguides/geddes/registry.md @@ -0,0 +1,90 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Registry + +## Accessing the Geddes Harbor Registry + +The Geddes Harbor registry is only accessible via campus networks and the Purdue VPN. Use a web browser to navigate to [geddes-registry.rcac.purdue.edu](https://geddes-registry.rcac.purdue.edu) and log in with your Purdue career account username and password. + +## Using the Geddes Registry Docker Hub Cache + +It's advised that you use the Docker Hub cache within Geddes to pull images for your deployments. There's a limit to how many images Docker Hub will allow to be pulled within a 24 hour period which Geddes does reach depending on user activity. This means if you're trying to deploy a workload without the cache, or have a currently deployed workload that needs migrated, restarted, or upgraded without the cache, there's a chance it will fail. + +To bypass this, use the Geddes cache url `geddes-registry.rcac.purdue.edu/docker-hub-cache/` in your image names. + +For example if you're wanting to pull a notebook from JupyterHub's Docker Hub repo e.g `jupyter/tensorflow-notebook:latest`, pulling it from the Geddes cache would look like this `geddes-registry.rcac.purdue.edu/docker-hub-cache/jupyter/tensorflow-notebook:latest`. + +If the image you are using is an "Official" docker image (like httpd or mongo) the URL will use "library" in the path instead of the Docker repository name: `geddes-registry.rcac.purdue.edu/docker-hub-cache/library/mongo:latest`. + +## Creating a registry + +1. Using a browser, login to [geddes-registry.rcac.purdue.edu](https://geddes-registry.rcac.purdue.edu) with your Purdue account username and password +2. From the main page click **create project**, this will act as your registry +3. Fill in a name and select whether you want the project to be public or private +4. Click **ok** to create and finalize + +## Tagging and Pushing Images to Your Harbor Registry + +1. Tag your image + + ``` + $ docker tag my-image:tag geddes-registry.rcac.purdue.edu/project-registry/my-image:tag + ``` + +2. Login to the Geddes registry via command line + + ``` + $ docker login geddes-registry.rcac.purdue.edu + ``` + +3. Push your image to your project registry + + ``` + $ docker push geddes-registry.rcac.purdue.edu/project-registry/my-image:tag + ``` + +## Creating a Robot Account for a Private Registry + +A robot account and token can be used to authenticate to your registry in place of having to supply or store your private credentials on multi-tenant cloud environments like Rancher/Geddes. + +1. Navigate to your project by logging into [geddes-registry.rcac.purdue.edu](https://geddes-registry.rcac.purdue.edu) +2. Navigate to the **Robot Accounts** tab and click **New Robot Account** +3. Fill out the form + * Name your robot account + * Select account expiration if any, select never to make permanent + * Customize what permissions you wish the account to have + * Click **Add** +4. Copy your information + * Your robot's account name will be something longer than what you specified, since this is a multi-tenant registry, Harbor does this to avoid unrelated project owners creating a similarly named robot account + * Export your token as JSON or copy it to a clipboard + + !!! note + Harbor does not store account tokens, once you exit this page your token will be unrecoverable. + +## Adding Your Private Registry to Rancher + +1. Select your **Project** from the top right dropdown +2. Using the far left dropdown menu navigate to **Storage** > **Secrets** +3. Click **Create** +4. Click **Registry** +5. Fill out the form + * Select **namespace** that will have access to the registry + * Give a **name** to the Registry secret (this is an arbitrary name) + * Under the **Data** tab ensure **custom** is selected + * Enter "geddes-registry.rcac.purdue.edu" under **Registry Domain Name** + * Enter your robot account's long name **eg. robot$my-registry+robot** as the **Username** + * Enter your robot account's token as the **password** + * Click **Create** + +## External Harbor Documentation + +* [Project Configurations](https://goharbor.io/docs/2.1.0/working-with-projects/project-configuration/) +* [Working With Images](https://goharbor.io/docs/2.1.0/working-with-projects/working-with-images/) diff --git a/docs/userguides/geddes/services.md b/docs/userguides/geddes/services.md new file mode 100644 index 00000000..49221133 --- /dev/null +++ b/docs/userguides/geddes/services.md @@ -0,0 +1,50 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Services + +A **Service** is an abstract way to expose an application running on Pods as a network service. This allows the networking and application to be logically decoupled so state changes in either the application itself or the network connecting application components do not need to be tracked individually by all portions of an application. + +## Service resources + +In Kubernetes, a Service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service). The set of Pods targeted by a Service is usually determined by a Pod selector, but can also be defined other ways. + +## Publishing Services (ServiceTypes) + +For some parts of your deployment you may need to expose an application externally from the cluster using **Services**. + +Kubernetes **ServiceTypes** allow you to specify what kind of Service you want. The default is ClusterIP. + +* **ClusterIP:** Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default ServiceType. +* **NodePort:** Exposes the Service on each Node's IP at a static port (the NodePort). A ClusterIP Service, to which the NodePort Service routes, is automatically created. You'll be able to contact the NodePort Service, from outside the cluster, by requesting `:`. +* **LoadBalancer:** Exposes the Service externally using a cloud provider's load balancer. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created. + +You can see an example of [exposing a workload using the **LoadBalancer** type](examples/database.md#expose-the-database-to-external-clients) in the examples section. + +### Ingress + +An **Ingress** is an API object that manages external access to the services in a cluster, typically HTTP/HTTPS. An Ingress is not a ServiceType, but rather brings external traffic into the cluster and then passes it to an Ingress Controller to be routed to the correct location. Ingress may provide load balancing, SSL termination and name-based virtual hosting. Traffic routing is controlled by rules defined on the Ingress resource. + +## Ingress Controller + +Geddes provides the [nginx](https://github.com/kubernetes/ingress-nginx/blob/main/README.md#readme) ingress controller configured to facilitate SSL termination and automatic DNS name generation under the `geddes.rcac.purdue.edu` subdomain. + +In the Examples section, there are detailed instructions about **[how to expose a service with an Ingress](examples/webserver.md)**. Here are the outline of major steps: + +1. Create a new **Deployment** under Workload +2. Set **Container Image** to the Docker image you want to use +3. Create a **Cluster IP** service to point our external accessible ingress for later +4. Setup Pod Label +5. Create a new **Ingress** page +6. Give the URL you would like to use for your web application under **Request Host** +7. Put the **Cluster IP** you created in *Step 1* to **Target Service** and **Port** +8. The default Ingress is **private**, which is only accessible within the Purdue network. To make a **public** one, add an **Annotation**: `kubernetes.io/ingress.class: "public"` + +Kubernetes provides additional information about [Ingress Controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) in the official documentation. diff --git a/docs/userguides/geddes/storage.md b/docs/userguides/geddes/storage.md new file mode 100644 index 00000000..99e020c6 --- /dev/null +++ b/docs/userguides/geddes/storage.md @@ -0,0 +1,188 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Storage + +Geddes has a software defined storage system that provides user-provisioned persistent data storage for container deployments. + +Ceph is used to provide block, filesystem and object storage on the Geddes Composable Platform. **File storage** provides an interface to access data in a file and folder hierarchy similar to Data Depot. **Block storage** is a flexible type of storage that is good for database workloads and generic container storage. **Object storage** is ideal for large unstructured data and features a REST based API providing an S3 compatible endpoint that can be utilized by the preexisting ecosystem of S3 client tools. + +!!! note + The integrity of the Ceph storage components is accomplished via a redundant disk system (3x replication). RCAC currently provides no backup of Geddes storage, either via snapshots or transfer of data to other storage. No disaster recovery other than the redundant disk systems is currently provided. + +## Storage Classes + +Geddes provides four different storage classes based on access characteristics and the performance needs of a workload. Performance classes should be used for workloads with high I/O requirements (databases, AI/ML). + +* `geddes-standard-singlenode` - Block storage based on SSDs that can be accessed by a single node (Single-Node Read/Write). +* `geddes-standard-multinode` - File storage based on SSDs that can be accessed by multiple nodes (Many-Node Read/Write or Many-Node Read-Only) +* `geddes-performance-singlenode` - Block storage based on NVMe drives that can be accessed by a single node (Single-Node Read/Write). +* `geddes-performance-multinode` - File storage based on NVMe drives that can be accessed by multiple nodes (Many-Node Read/Write or Many-Node Read-Only) + +### Block and Filesystem Storage Provisioning in Deployments + +Block and Filesystem storage can both be provisioned in a similar way. + +1. While deploying a Workload, click the Storage tab and click **Add Volume**… +2. Select "**Create Persistent Volume Claim**" +3. Set a unique Persistent Volume Claim Name, i.e. "`-volume`" +4. Select a Storage Class. The default storage class is "geddes-standard-singlenode". +5. Select an Access Mode. The "geddes-standard-singlenode" class only supports Single-Node Read/Write. +6. Request an amount of storage in Gigabytes +7. Provide a Mount Point for the persistent volume: i.e */data* + +## Backup Strategies + +Developers using the Geddes platform should have a backup strategy in place to ensure that your data is safe and can be recovered in case of a disaster. Below is a list of methods that can be used to backup data on Persistent Volume Claims. + +### Copying Files to and from a Container + +The `kubectl cp` command can be used to copy files into or out of a running container. + +``` +# get pod id you want to copy to/from +kubectl -n get pods + +# copy a file from local filesystem to remote pod +kubectl cp /tmp/myfile /:/tmp/myfile + +# copy a file from remote pod to local filesystem +kubectl cp /:/tmp/myfile /tmp/myfile +``` + +This method requires the `tar` executable to be present in your container, which is usually the case with Linux images. More info can be found in the kubectl [docs](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#cp). + +### Copying Directories from a Container + +The `kubectl cp` command can also be used to recursively copy entire directories to local storage or places like Data Depot. + +``` +# get pod id you want to copy to/from +kubectl -n get pods + +# copy a directory from remote pod to local filesystem +kubectl cp /:/pvcdirectory /localstorage +``` + +### Backing up a Database from a Container + +The `kubectl exec` command can be used to create a backup or dump of a database and save it to a local directory. For instance, to backup a MySQL database with kubectl, run the following commands from a local workstation or cluster frontend. + +``` +# get pod id of your database pod +kubectl -n get pods + +# run mysqldump in the remote pod and redirect the output to local storage +kubectl -n exec -- mysqldump --user= --password= my_database > my_database_dump.sql +``` + +### Backups using common Linux tools + +If your container has the OpenSSH client or rsync packages installed, one can use the `kubectl exec` command to copy or synchronize to another storage location. + +``` +# get pod id of your pod +kubectl -n get pods + +# run scp to transfer data from the pod to a remote storage location +kubectl -n exec -- scp -r /data username@negishi.rcac.purdue.edu:~/backup +``` + +### Automating Backups + +Kubernetes CronJob resources can be used with the commands above to create an automated backup solution. For more information, refer to the Kubernetes [documentation](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/). + +## Object Storage + +Geddes provides S3 compatible object storage from the endpoint [s3-prod.geddes.rcac.purdue.edu](https://s3-prod.geddes.rcac.purdue.edu). + +S3 access can be requested by [contacting support](https://www.rcac.purdue.edu/help). Access keys will be provided via Filelocker. + +### Accessing Object Storage + +The S3 endpoint provided by Geddes can be accessed in multiple ways. Two popular options for interacting with S3 storage via the command line and GUI are listed below. + +**S3cmd** is a free command line tool for managing data in S3 compatible storage resources that works on Linux and Mac. + +* Download: [s3tools.org/download](https://s3tools.org/download) +* How-To Documentation: [s3tools.org/s3cmd-howto](https://s3tools.org/s3cmd-howto) + +**Cyberduck** is a free server and cloud storage browser that can be used on Windows and Mac. + +1. [Download and install Cyberduck](https://cyberduck.io/download/) +2. Launch Cyberduck +3. Click **+ Open Connection** at the top of the UI. +4. Select **S3** from the dropdown menu +5. Fill in **Server**, **Access Key ID** and **Secret Access Key** fields +6. Click **Connect** +7. You can now right click to bring up a menu of actions that can be performed against the storage endpoint + +Further information about using Cyberduck can be found on the [Cyberduck documentation site](https://docs.cyberduck.io/). + +## Accessing and Mounting Depot + +[Contact support](https://www.rcac.purdue.edu/help) to request access. Make sure to provide the Geddes namespace that will be accessing depot and the `$PATH` to your user/lab depot space. Once access has been approved and an admin has created the needed Persistent Volumes for depot you can move on to the steps below. + +The overall process is: + +1. Submit request. + 1. An admin will create the needed Persistent Volume needed to access your depot space and will provide you with the name `pv-depot-` +2. Create Kubernetes secrets for Depot username/password authentication. +3. Create a Persistent Volume Claim via Rancher UI or kubectl. +4. Use that claim for your workloads/pods to mount depot. + +**Create k8s username/password secret for depot auth** + +1. From the Rancher UI, use the left navigation bar to select **Storage > Secrets** +2. Click **Create** at the top right +3. Select **Opaque** and fill out the form. + 1. Make sure to select the namespace that will be accessing depot + 2. Name should be `depot-credentials-` + 3. Under the data tab click **add** to create a second secret key field + 4. Provide key/values + 1. Key: **username** value: `` + 2. Key: **password** value: `` + 5. Click **Create** at the bottom right + +**Create a PersistentVolumeClaim for Depot (Rancher UI)** + +1. From the Rancher UI, use the left navigation bar to select **Storage > PersistentVolumeClaims** +2. Click **Create** at the top right and fill out the form + 1. Make sure to select the namespace that will be accessing depot + 2. Name should be `pvc-depot-` + 3. Select **Use an existing Persistent Volume** + 4. Use the dropdown to the immediate right to select `pv-depot-` + 5. Click **Customize** in the form tab on the left + 6. Select **Many Nodes Read-Write** + 7. Click **Create** at the bottom right. + +**Create a PersistentVolumeClaim for Depot (kubectl)** + +1. Create a yaml file i.e **depot-pvc.yaml** with the code below + + ``` + apiVersion: v1 + kind: PersistentVolumeClaim + metadata: + name: pvc-depot- + namespace: + spec: + accessModes: + - ReadWriteMany + resources: + requests: + storage: 1Mi + volumeName: pv-depot- + storageClassName: "" + ``` + +2. Replace all the `` and `` with the appropriate values. + 1. Do not include the example angle brackets `< >` in your code +3. Apply the yaml with the command `kubectl apply -f depot-pvc.yaml` diff --git a/docs/userguides/geddes/troubleshooting.md b/docs/userguides/geddes/troubleshooting.md new file mode 100644 index 00000000..aa7335ba --- /dev/null +++ b/docs/userguides/geddes/troubleshooting.md @@ -0,0 +1,81 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Troubleshooting + +## Useful Links + +There are many valuable Kubernetes troubleshooting guides readily accessible on the Internet. Instead of duplicating them here, we provide links to external documentation that has been useful for users of the Geddes platform. + +* [Debugging Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/) +* [Debugging Services](https://kubernetes.io/docs/tasks/debug/debug-application/debug-service/) +* [Pod Failures](https://kubernetes.io/docs/tasks/debug/debug-application/determine-reason-pod-failure/) +* [Get a Shell on a Running Container](https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/) + + Through the Geddes UI, the equivalent method is clicking the vertical ellipsis and selecting "Execute Shell". + +## Create a Pod for Debugging + +Many times, users want to start a simple persistent Pod from a container image like Alpine or Ubuntu to do troubleshooting. The following YAML will deploy an Alpine Linux pod in a namespace that sleeps for 24 hours. + +``` +apiVersion: v1 +kind: Pod +metadata: + name: debug + namespace: + labels: + app: debug +spec: + containers: + - image: geddes-registry.rcac.purdue.edu/docker-hub-cache/library/alpine + command: + - "sleep" + - "86400" + name: debug +``` + +One can also launch a persistent Pod by specifying the sleep command via the Geddes UI. + +![Launching a persistent Pod via the Geddes UI](/assets/images/userguides/geddes/pod-debugging-1.png) + +## Permission Denied on PVC for non-root User + +If your container or process runs as a non-root user and you see a "Permission denied" error, you may need to set the fsGroup SecurityContext on your Pod so permissions are configured correctly on the PVC. This can be done in the Pod's spec. + +``` +securityContext: + fsGroup: +``` + +Where gid is the group id your container is running as, or the group id of the process that is trying to write to the PVC. + +This setting can also be applied under the Pod menu when deploying a workload via the Geddes UI. + +![Setting the fsGroup SecurityContext via the Geddes UI](/assets/images/userguides/geddes/pod-debugging-2.png) + +## Pull Rate Limit Error + +**Symptom:** + +ImagePullBackoff Error with message `Failed to pull image ":": rpc error: code = Unknown desc = toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit` + +**Solution:** + +Use the Geddes Registry [Docker Hub Cache](registry.md#using-the-geddes-registry-docker-hub-cache) to pull your image from Docker Hub. + +## Ingress 413 Content Too Large Errors + +By default, the Ingress controller on Geddes can handle requests up to 1 MB in size. If you need to send requests larger than 1 MB you can increase the size with the following Ingress annotation. Using "0" will allow unlimited size. + +``` +metadata: + annotations: + nginx.ingress.kubernetes.io/proxy-body-size: "0" +``` diff --git a/docs/userguides/geddes/workloads.md b/docs/userguides/geddes/workloads.md new file mode 100644 index 00000000..36ebfc9b --- /dev/null +++ b/docs/userguides/geddes/workloads.md @@ -0,0 +1,24 @@ +--- +tags: + - Geddes +authors: + - jin456 + - goughes +search: + boost: 2 +--- + +# Workloads + +## Deploy a Workload + +1. Using the top right dropdown select the **Project** or **Namespace** you wish to deploy to. +2. Using the far left menu navigate to **Workload** +3. Click **Create** at the top right +4. Select the appropriate **Deployment Type** for your use case + * Select **Namespace** if not already done from step 1 + * Set a unique **Name** for your deployment, **i.e.** "myapp" + * Set **Container Image**. Ensure you're using the Geddes registry for personal images or the Geddes registry docker-hub cache when pulling public docker-hub specific images. **e.g**: `geddes-registry.rcac.purdue.edu/my-registry/myimage:tag` or `geddes-registry.rcac.purdue.edu/docker-hub-cache/library/image:tag` + * Click **Create** + +See the [Examples](examples/index.md) section for complete walkthroughs of deploying a database, a web server, and an R Shiny app. diff --git a/mkdocs.yml b/mkdocs.yml index 1b856d70..fcbedc98 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -162,8 +162,23 @@ nav: - Gateway (Open OnDemand): userguides/scholar/gateway.md - Compiling Source Code: userguides/scholar/compile.md - Frequently Asked Questions: userguides/scholar/faqs.md + - Geddes: + - userguides/geddes/index.md + - Overview of Geddes: userguides/geddes/overview.md + - Biography of Lanelle Geddes: userguides/geddes/biography.md + - Concepts: userguides/geddes/concepts.md + - Access: userguides/geddes/access.md + - Registry: userguides/geddes/registry.md + - Workloads: userguides/geddes/workloads.md + - Services: userguides/geddes/services.md + - Storage: userguides/geddes/storage.md + - Examples: + - userguides/geddes/examples/index.md + - Database: userguides/geddes/examples/database.md + - Web Server: userguides/geddes/examples/webserver.md + - R Shiny: userguides/geddes/examples/r-shiny.md + - Troubleshooting: userguides/geddes/troubleshooting.md - Negishi: https://www.rcac.purdue.edu/knowledge/negishi - - Geddes: https://www.rcac.purdue.edu/knowledge/geddes - Hammer: https://www.rcac.purdue.edu/knowledge/hammer - Rossmann: https://www.rcac.purdue.edu/knowledge/rossmann - Weber: https://www.rcac.purdue.edu/knowledge/weber