Red Hat Ansible development workspaces combine Red Hat OpenShift Dev Spaces with Ansible development tools to give automation developers a browser-based, pre-configured VS Code environment in about five minutes. The environment is defined declaratively via a devfile.yaml, includes tools like ansible-lint, ansible-creator, molecule, and ansible-builder, and eliminates local installs while centralizing governance. A tiered image strategy (base, org/domain, team, personal) lets platform teams enforce standards while allowing controlled customization, with automatic rebuilds on security patches and self-service pull requests for image changes.
Table of contents
Benefits of OpenShift Dev SpacesWhat if it took five minutes to onboard your automation developers?What the developer seesWhy this matters for enterprise teamsTiered image strategy: Customization without compromiseSelf-service without bottlenecksFrom local dev container to cloud workspaceThe content lifecycle in a governed workspaceGetting startedWhat's nextAdditional resourcesQuestions this post answers
What is the difference between using Ansible dev containers locally versus Ansible development workspaces on OpenShift Dev Spaces?
Both use the same container image and deliver high environment consistency, but local dev containers require each developer to have a container runtime like Docker or Podman, disk space, and local permissions, while OpenShift Dev Spaces removes those requirements since infrastructure is managed by OpenShift and developers only need a browser. OpenShift Dev Spaces also adds centralized governance over resource limits, image versions, and access policies. daily.dev surfaces practical comparisons like this for teams weighing local versus cloud automation environments.
How does the tiered image strategy work for Ansible development tools container images across teams?
A base image managed by Red Hat provides core Ansible development tools for everyone, an org/domain tier adds domain-specific system packages managed by the platform team, a team tier adds team-specific extras managed by the team lead, and a personal opt-in tier lets individual developers add niche packages, with stale personal images cleaned up after 90 days and popular personal packages promoted to the team tier. Teams designing layered container strategies can track patterns like these on daily.dev.
What package dependencies are needed for network automation versus Windows automation with Ansible?
Network automation typically requires libssh-devel, python3-netaddr, and paramiko, while Windows automation requires krb5-workstation and python3-pykerberos. Cloud automation needs awscli and python3-boto3, and Ansible Automation Platform config-as-code work needs httpie and python3-pyyaml, each layered as a domain-specific image on top of a shared base image. daily.dev helps automation engineers keep track of ecosystem-specific tooling requirements like these.