Managing Developer Workspaces

To create a devfile, ensure 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. 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

If you work 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 to run a Nodejs app, as our image also contains everything needed for Nodejs development. It also adds another image called mongodb-36-rhel7 that provides a pre-configured instance of a MongoDB that can be used for development. You also 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

You can combine IBM z/OS Connect Designer with Wazi for Dev Spaces, to provide fully integrated workspaces that enables you to graphically develop your APIs based on your COBOL source, and edit and test the generated code all in one place. The z/OS Connect Designer documentation 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 runs the z/OS Connect Designer web server and the other runs the development tools. Within your workspace, you can access both containers through terminals. Both container specifications mount the common source folder, so source code generated by the z/OS Connect Designer container can be accessed and edited by tools provided by the Wazi container.

To share user settings for Z Open Editor with your project team. For example, provide custom values for the "files.associations" setting to define the file extensions that you are using with your source code files in your Git project, which are not in the default set defined for Z Open Editor. As "files.associations" is a global (Window-level) user setting, you cannot provide in your project's ".vscode/settings.json" file. This is because Git repositories are loaded into a multi-root workspace in Dev Spaces, which require global settings to be defined in the ".code-workspace" file. Learn more about multi-root workspaces in the VS Code documentation and the Dev Spaces documentation.

Devfiles do not provide the ability to list VS Code user settings, but you can include a ".code-workspace" file at the top-level of your Git repository next to your devfile that is loaded when you start a new workspace. For the example above, the content of that file looks like this

{
  "folders": [
    {
      "name": "zopeneditor-sample",
      "path": "."
    }
  ],
  "settings": {
    "files.associations": {
      "*.cbl-custom": "cobol"
    }
  },
  "extensions": {
    "recommendations": ["ibm.zopeneditor", "redhat.vscode-yaml"]
  }
}

You can also include the VS Code extension recommendations, so you do not need to provide a ".vscode/extensions.json" file.

To standardize settings across many different projects and many different Git repositories, you can use ConfigMaps to define settings for your user account or many different accounts by replicating the map to their namespaces.

• See the Red Hat documentation Applying editor configurations for how to write such a ConfigMap.

• See the Eclipse Che documentation Configuring a user namespace with details to share the ConfigMaps with other users.

On the desktop, Zowe CLI and Zowe Explorer use their secure credentials store, which stores credentials to z/OS systems in a local operation system in a 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 needs to be configured differently when it runs here.

When you create a workspace in Dev Spaces that loads Zowe Explorer. The first time it starts up, it prompts you with a message that the default credentials manager is not found and is disabled. The dialog then asks you to reload the current browser window and provides a button to do so. After it restarts, Zowe Explorer is ready to use. Zowe Explorer disables the credentials manager by changing a Remote VS Code setting, that you can find by following these steps:

1. Go to the Remote settings tab of the Settings editor.

2. Search for the word "Security".

3. Confirm that the setting Zowe > Security: Secure Credentials Enabled (zowe.security.secureCredentialsEnabled) is disabled.

This 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.

Now, you can create 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 use these entries.

The property "autoStore": false disables storing any credentials inside the team configuration file. Set it to true to enable it. If disabled, it prompts you 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, it prompts for username and password credentials. Once entered, those values are 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 is also stored in the team configuration file, but it expires after a while (determined by your RAE API or z/OSMF administrator), so that OpenShift administrators cannot 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 works on a new capability called Secure Credential Store Plug-in for Zowe CLI, which makes 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 repository following the instructions provided.