Using Z Open Editor with Dev Containers

The devcontainer technology introduced in Using Z Open Editor on GitHub Codespaces can be used in local or remote systems running Docker containers. This could be interesting for organizations that cannot do their development on github.com and also do not operate OpenShift clusters. Instead developers could use Linux servers, which the development organization maintains, to host devcontainers in-house. In combination with an in-house container registry a development organization could provide prefabricated container images for their developers that provide all the required development tools and even VS Code extension so developers do not have to fetch anything from the internet themselves.

The examples shown in Using Z Open Editor on GitHub Codespaces that ran on GitHub Codespaces can be reused as is without modification to run in local or remote containers as well. Hence, once you have created a Dev Container specification for your project you have the additional choices to run your container

• locally on your developer machine using Docker, or an equivalent technology such as Podman,
• another remote system such as a Linux box hosted by your organization,
• a virtual server instance hosted by another Cloud provider such as IBM Cloud.

Running a Dev Container locally

The VS Code user documentation provides a Getting Started guide for how to run such containers listing the prerequisites and steps to perform. After setting up the prerequisites (installing Docker and the Dev Containers VS Code extension) you can use the Z Open Editor sample devcontainer introduced in Using Z Open Editor on GitHub Codespaces by just following these simple steps:

• Fork or clone our repository https://github.com/IBM/zopeneditor-sample
• Check out the branch "devcontainer"
• If you have the "Dev Container" VS Code extension and Docker installed, VS Code will prompt you that it found a dev container asking you if should start it in your local Docker. Click "Reopen in Container".
• It will prompt you now saying that it found two devcontainer.json files in our sample repository. "Z Open Editor Container" and "Z Open Editor Container with VPN". For now select the first option. The second one you could use in the same way as described in Connecting to a z/OS system using a VPN if you need your container to use a VPN to access your z/OS system.
• VS Code will now start building the image and starting the container, which might take a few minutes the first time.
• Finally, VS Code will prompt to reload the editor, which will then open the remote workspace inside the container.

Inside the container workspace you will find a copy of your workspace files. It has even mirrored your Git repository and configuration into the container, so that you can just continue working with this project as if it would be local. To test that you are indeed working inside the container, open the Terminal window and type whoami. It will respond with vscode and not your regular user account.

If you missed the initial prompt you can always execute loading the workspace in a container via the command palette with "Dev Containers: Reopen in Container". The VS Code documentation has more details about all the other commands you can execute.

Once you have this image created you could export it and share it with other colleagues. It will have everything they need including the VS Code extensions such as Z Open Editor or Zowe Explorer, which could be useful if developers do not have access to the internet for downloading extensions from the VS Code Marketplace. Just be aware that personal configuration files such as the .gitconfig file were copied into the image. For creating the image teams need to sanitize those files and replace them with generic versions.

Running a Dev Container remotely

Instead of running your remote workspace in a local Docker container you could run it on a remote Linux system in a Docker container there. VS Code also supports just running a workspace on a remote system directly, but only when using a container runtime on the remote system you can ensure the common workspace configuration that the dev container file provides. You therefore need access to such as remote system that also has Docker, Podman or an equivalent container runtime installed.

• Select "Remotes (Tunnels/SSH) in drop-down in the Remote Explorer.
• If you have your remote system listed in your personal ssh/config file it will be listed. Otherwise you can use the + button to create a new entry.
• Connect to the remote system using either of the two buttons next to the system name opening in current or new window.
• When connected you see that the File Explorer offers options to open existing folder or to clone a repository.
• Clone the https://github.com/IBM/zopeneditor-sample repository and check out the branch "devcontainer".
• Then use the same prompt or command as described in the instructions above to build and run the container on the remote system.

See the VS Code documentation for all the details.