Managing Developer Workspaces

Starting a sample workspace

The Getting started with Dev Spacesopen in new window section of the Dev Spaces user guide gives a great overview to creating and running workspaces.

To start a workspace using Z Open Editor and Zowe Explorer we provided an example in our own Quickstart tutorial. Remember, that you can perform the steps of the "Create a workspace with the Z Open Editor sample repository" section with the Red Hat Developer Sandbox as well as any other Red Hat OpenShift Dev Spaces deployment that has access to the public internet for cloning our Z Open Editor sample repository.

Start a custom workspace

To create a custom workspace with your own configuration settings you need to add a devfile to the source code Git repository that you want to load. Devfiles are yaml text files used for development environment customization. Use them to configure a devfile to suit your specific needs and share the customized devfile across multiple workspaces to ensure identical user experience and build, run, and deploy behaviors across your team.

The devfile schema is being developed as an open specification at https://devfile.ioopen in new window. The Red Hat documentation provides an overview and resource listopen in new window for learning more about devfiles and their syntax.

In addition to the default devfile, Dev Spaces allows users to use a customized devfile to create a workspace. These are two methods using your own devfile:

Provide your own devfile in the Git repositoryopen in new window with your source code and start your workspace by just providing the https url to your Git repository.
Create a workspace from a raw devfile URLopen in new window. For example, your organization could manage a repository of standardized devfiles that your team can use for different types of development projects pulling together standard sets of images and tools.

Creating custom devfiles

When creating a devfile ensure that it uses the IBM Developer for z/OS on Dev Spaces container image (called "ibm-wazi-for-devspaces-sidecar") that provides the capabilities needed for enterprise development projects. You can copy the default devfile shown below, paste it into your projects' Git repository, and make modifications.

Simple devfile for enterprise development projects using the IBM Developer for z/OS on Dev Spaces image:

schemaVersion: 2.3.0
metadata:
  name: idzee-devspaces

components:
  - name: zowe
    volume:
      size: 100Mi
  - name: idzee-terminal
    container:
      image: icr.io/wazi-code/ibm-wazi-for-devspaces-sidecar:latest
      memoryLimit: 3072Mi
      mountSources: true
      volumeMounts:
        - name: zowe
          path: /home/user/.zowe

Example devfile for hybrid application development

If you are working on a hybrid application and want to combine COBOL development with a stack for Nodejs and MongoDB, you can modify the first sample above in the following way to combine content from two of the Dev Spaces stacks. In this case, the usage of the IBM Developer for z/OS on Dev Spaces ibm-wazi-for-devspaces-sidecar container is extended to also provide environment variables and endpoints for running a Nodejs app, as our image also contains everything needed for Nodejs development. It then also added another image called mongodb-36-rhel7 that provides a pre-configured instance of a MongoDB that can be used for development. Also, you find two more mounted storage volumes for npm and mongo in addition to the Zowe profile storage the IBM Developer for z/OS on Dev Spaces image is using.

schemaVersion: 2.2.0
metadata:
  name: wazi-devspaces
components:
  - name: wazi-node
    container:
      image: icr.io/wazi-code/ibm-wazi-for-devspaces-sidecar:latest
      memoryLimit: 3072Mi
      env:
        # The values below are used to set up the environment for running the application
        - name: SECRET
          value: 220fd770-c028-480d-8f95-f84353c7d55a
        - name: NODE_ENV
          value: production
      endpoints:
        - exposure: public
          name: nodejs
          targetPort: 8080
      mountSources: true
      sourceMapping: /projects
      volumeMounts:
        - name: zowe
          path: /home/user/.zowe
        - name: npm
          path: /home/user/.npm
  - name: mongo
    container:
      image: registry.redhat.io/rhscl/mongodb-36-rhel7:1-50
      env:
        - name: MONGODB_USER
          value: user
        - name: MONGODB_PASSWORD
          value: password
        - name: MONGODB_DATABASE
          value: guestbook
        - name: MONGODB_ADMIN_PASSWORD
          value: password
      endpoints:
        - name: mongodb
          exposure: internal
          targetPort: 27017
      memoryLimit: 512Mi
      mountSources: false
      volumeMounts:
        - name: mongo-storage
          path: /var/lib/mongodb/data
  - name: zowe
    volume:
      size: 100Mi
  - name: npm
    volume:
      size: 1G
  - name: mongo-storage
    volume:
      size: 1G
commands:
  - id: 1-run
    exec:
      label: "Run the application"
      component: nodejs
      workingDir: ${PROJECTS_ROOT}/nodejs-mongodb-sample
      commandLine: "npm install && node --inspect=9229 app.js"
      group:
        kind: run

Example devfile for integrating z/OS Connect Designer

You can combine IBM z/OS Connect Designer with Wazi for Dev Spaces, providing fully integrated workspaces that allow you to graphically develop your APIs based on your COBOL source and edit and test generated code all in one place. The z/OS Connect Designer documentationopen in new window provides devfile examples for Eclipse Che that you can combine with our IBM Developer for z/OS on Dev Spaces devfile as follows:

schemaVersion: 2.2.0
metadata:
  name: api-project-name
components:
  - name: wazi
    container:
      image: icr.io/wazi-code/ibm-wazi-for-devspaces-sidecar:latest
      memoryLimit: 3072Mi
      mountSources: true
      sourceMapping: /projects
      volumeMounts:
        - name: zowe
          path: /home/user/.zowe
  - name: zowe
    volume:
      size: 100Mi
  - name: zosconnect
      container:
        endpoints:
          - exposure: public
            name: zosconnect-ui
            path: /zosConnect/designer/
            protocol: http
            targetPort: 9080
        env:
          - name: ZCON_DESIGNER_PROJECT
            value: /projects/api-project-name/apiProject
        image: 'icr.io/zosconnect/ibm-zcon-designer:3.0.78'
        memoryLimit: 4927M
        mountSources: true

The example above shows how the Wazi and z/OS Connect images get pulled into separate containers in your workspace: one running the z/OS Connect Designer web server and the other running development tools. From within your workspace you can access both containers via terminals. Both container specification mount the common sources folder so source code generated by the z/OS Connect Designer container can be accessed and edited by tools provided by the Wazi container.

Configuring Zowe Explorer

Next to the Z Open Editor VS Code extension, Zowe Explorer is key to the z/OS Dev Spaces user experience. Zowe Explorer works inside Dev Spaces almost in the same ways as for VS Code for Desktop with some minor exceptions as described in this section.

Secure credential management

On the desktop, Zowe CLI and Zowe Explorer use their secure credentials storeopen in new window, which stores credentials to z/OS systems in a local operation system specific way, such as the Keychain on MacOS. Dev Spaces runs on OpenShift and the same credentials management technology is not available. Therefore, Zowe CLI and Zowe Explorer need to be configured differently when running here.

When you create a workspace in Dev Spaces that loads Zowe Explorer, the first time it starts up it will prompt you with a message that the default credentials manager could not be found and was disabled. The dialog then ask you to reload the current browser window and provide a button to do so. After it restarts Zowe Explorer will be ready to be used. Zowe Explorer disabled the credentials manager by changing a Remote VS Code setting that you can find following these steps:

Go to the Remote settings tab of the Settings editor.
Search for the word "Security".
Conform that the setting Zowe > Security: Secure Credentials Enabled (zowe.security.secureCredentialsEnabled) is disabled.

This has switched Zowe Explorer and Zowe CLI to not look for a secure credentials manager. Under the cover, it also modified the file ~/.zowe/settings/imperative.json in the workspace user's home directory.

Team configuration file

Now, you can start creating a team configuration file as documented in Creating a configuration profile in Zowe Explorer v3.0.0. However, in the json file, you need to remove all entries "secure": [] as there is no credentials manager configured that will use these entries.

The property "autoStore": false will disable storing any credentials inside the team configuration file. Set it to true to enable it. If disabled, you will be prompted for username and password credentials every time your start using the Zowe Explorer views. The views remember these credentials in memory until you click the Refresh button in the Zowe Explorer views or reload or restart your workspace. If set enabled, you can work with credentials stored inside the team configuration file in two ways:

When you request content for the first time, such as loading a list of data sets into the Data Sets view, you get prompted for username and password credentials. Once entered, those values will be saved and persisted in your team configuration file. This file is stored inside an encrypted volume in OpenShift that only you and administrator can access.
Instead of waiting for a user prompt, you can use token-based authentication that provides you with a time-limited access token. This token will also be stored in the team configuration file, but it will expire after a while (determined by your RAE API or z/OSMF administrator), so that OpenShift administrators will not be able to use it after its expiration. To request a token, simply right-click a profile in any Zowe Explorer view and select Login to Authentication Service. To learn more about this authentication, see the instructions that are detailed in the section Single sign-on support for RSE profiles in Zowe Explorer.

Note: The Zowe project is working on a new capability called Secure Credential Store Plug-in for Zowe CLIopen in new window, which will make configuring credentials consistent with managing secrets in Kubernetes and how secrets are managed in IBM Wazi for Dev Spaces as described on the page Managing secrets. Until this technology is fully tested and integrated into Wazi for Dev Spaces, you can try it out from the open source Git repositoryopen in new window following the instructions provided there.

# Managing Developer Workspaces

# Starting a sample workspace

# Start a custom workspace

# Creating custom devfiles

# Example devfile for hybrid application development

# Example devfile for integrating z/OS Connect Designer

# Configuring Zowe Explorer

# Secure credential management

# Team configuration file