Remove some references to LASP image registry

docs/source/workflows/docker/beginner_guide_to_docker.md

@@ -41,8 +41,7 @@ useful if you will be running multiple images in tandem, attaching volumes or ne
 generally find yourself running the same commands for creating containers and want to optimize that.
 
 **Docker Registry:** A registry or archive store is a place to store and retrieve docker images. This is one way to
-share already-built docker images. LASP has a private repository, in the form of the
-[LASP docker registry](lasp_docker_registry).
+share already-built docker images. LASP has a private repository, in the form of the LASP docker registry.
 
 So, you define a Docker *image* using a *Dockerfile* and/or a *Docker Compose* file. Running this image produces a
 Docker *container*, which runs your code and environment. An image can be pushed up to a *registry*, where anyone with
@@ -143,10 +142,6 @@ has successfully exited with `docker ps -a`. The `CMD` is how most Docker contai
 intervention work. For an example of a system where that's operating, you can read the documentation on the [TIM tests
 in Docker](https://confluence.lasp.colorado.edu/display/DS/Containerize+TIM+Processing+-+Base+Image).
 
-Next steps, beyond going more in depth with the TIM dockerfiles, would be to learn about using the [LASP docker
-registry](lasp_docker_registry). Other topics include [Docker compose](docker_compose_examples), running Docker on
-[M1 chips](running_docker_with_m1), and other pages under the [Docker Guidelines](index).
-
 ## Docker Cheat Sheet
 
 Here is a list of Docker commands that might be useful to have as a shorthand:
@@ -159,7 +154,7 @@ docker build --platform linux/amd64 -f <filename> -t <name>:latest .
 docker run --platform linux/amd64 -it --name <container name> <image name>:latest
 
 # Login to docker registry
-docker login docker-registry.pdmz.lasp.colorado.edu
+docker login <registry_hostname>
 
 # View docker images
 docker images

docs/source/workflows/docker/containerizing_idl_with_docker.md

@@ -19,7 +19,7 @@ This document provides a preliminary implementation of IDL in a Docker container
 * Provided that the host machine has LASP VPN access (for licensing purposes), the containerized IDL should work
   directly "out of the box" (i.e., no manual post-container creation steps are required).
 * Although both the IDL and IDLDE images can be built locally using the Dockerfiles below, they are also available from
-  the [LASP Image Registry](lasp_docker_registry).
+  the LASP Image Registry.
 
 ## Dockerfile
 
@@ -42,7 +42,7 @@ RUN apt-get update && apt-get install -y \
   && rm -rf /var/lib/apt/lists/*
 
 # Download IDL package, unarchive it, remove package, perform silent install using answer file
-RUN curl -O https://artifacts.pdmz.lasp.colorado.edu/repository/datasystems/idl/installers/idl87.tar.gz \
+RUN curl -O <url_to_idl87.tar.gz> \
   && tar -xzf ./idl87.tar.gz && rm -f ./idl87.tar.gz \
   && sh ./install.sh -s < ./silent/idl_answer_file
 
@@ -139,7 +139,7 @@ The following demonstrates how to utilize IDL by directly interacting with a run
 (optional) container name is `idl_container` and the name of the (previously created) image is `idl_image`:
 
 ```bash
-(base) MacL3947:idl stmu4541$ docker container run -it --name=idl_container idl_image
+(base) MacL3947:idl $ docker container run -it --name=idl_container idl_image
 IDL 8.7.3 (linux x86_64 m64).
 (c) 2020, Harris Geospatial Solutions, Inc.
 
@@ -150,7 +150,7 @@ https://harrisgeospatial.flexnetoperations.com
 IDL> print, ((cos(45.0d*(!PI/180.0d)))^2 + (sin(45.0d*(!PI/180.0d)))^2).tostring()
 1.0000000000000000
 IDL> exit
-(base) stmu4541@MacL3947:~/projects/docker/idl$
+(base) <username>@<hostname>:~/projects/docker/idl$
 ```
 
 ## Cross-container Access
@@ -293,21 +293,21 @@ OS.
 
 Create an IDL container named `idl_container` from the `idl_image` image generated by the Dockerfile included above, and
 include a bind mount to a directory on the host machine. In this example, the host directory is
-`/Users/stmu4541/projects/docker/src`, and is bind mounted to a directory named `/src` in the IDL container:
+`/Users/<username>/projects/docker/src`, and is bind mounted to a directory named `/src` in the IDL container:
 
 ```bash
-docker container run -d -v /Users/stmu4541/projects/docker/src:/src --name=idl_container idl_image
+docker container run -d -v /Users/<username>/projects/docker/src:/src --name=idl_container idl_image
 ```
 
-The container is named `idl_container`, and the `/Users/stmu4541/projects/docker/src` directory on the host is bind
+The container is named `idl_container`, and the `/Users/<username>/projects/docker/src` directory on the host is bind
 mounted to the `/src` directory in the container.
 
 Now create the non-IDL container named `centos_container`:
 
 ```bash
 docker container run --rm -it \
   --name=centos_container \
-  -v /Users/stmu4541/projects/docker/src:/src \
+  -v /Users/<username>/projects/docker/src:/src \
   -v /var/run/docker.sock:/var/run/docker.sock \
   -v /usr/bin/docker:/usr/bin/docker \
   lentos bash
@@ -316,10 +316,10 @@ docker container run --rm -it \
 Here, `lentos`, which immediately precedes the bash command specifies the official `centos` image.
 
 The three bind mounts are identical to those described in Solution 1 except that the named volume mount (`SharedData`)
-has been replaced by a bind mount to a directory (`/Users/stmu4541/projects/docker/src`) on the host machine.
+has been replaced by a bind mount to a directory (`/Users/<username>/projects/docker/src`) on the host machine.
 
-The `/Users/stmu4541/projects/docker/src` directory on the host machine, and the `/src` directories on both containers
-refer to the same file system. In other words, any file that resides in the `/Users/stmu4541/projects/docker/src` host
+The `/Users/<username>/projects/docker/src` directory on the host machine, and the `/src` directories on both containers
+refer to the same file system. In other words, any file that resides in the `/Users/<username>/projects/docker/src` host
 directory or the `/src` directory in the non-IDL container, is visible to the `/src` directory of the IDL container.
 
 ## Jenkins as the Non-IDL Container
@@ -381,18 +381,18 @@ As always, this image build command must be run in the same directory as the rel
 #### Pull the IDLDE Image from the LASP Image Registry
 
 The image can be built locally using the above Dockerfiles and the `docker image build` command, or it can be obtained
-from the [LASP Image Registry](lasp_docker_registry). To pull the image, log into the LASP Image Registry and use the
+from the LASP Image Registry. To pull the image, log into the LASP Image Registry and use the
 `pull` command:
 
 ```bash
-docker pull docker-registry.pdmz.lasp.colorado.edu/tsis/idlde_centos7:latest
+docker pull <registry_url>/tsis/idlde_centos7:latest
 ```
 
 I recommend re-tagging the image for convenience (this will not create an additional copy of the image, it acts more
 like a symbolic link to the same image):
 
 ```bash
-docker image tag docker-registry.pdmz.lasp.colorado.edu/tsis/idlde_centos7 idlde_image
+docker image tag <registry_url>/tsis/idlde_centos7 idlde_image
 ```
 
 #### Run the Containerized IDLDE on Linux

docs/source/workflows/docker/index.rst

@@ -9,7 +9,5 @@ Docker
     docker_compose_examples
     export_display_with_docker
     jenkins_job_builder
-    lasp_docker_registry
-    lasp_image_registry
     multi_stage_builds
     running_docker_with_m1