Introduce Workshop: composable, secure, and fast development environments on Ubuntu. Learn how to create sandboxed, reproducible environments for running agents with different development stacks consistently and securely.
Dmitry Lyfar
Engineering Manager at Canonical
Can you explain how this would differ from devcontainers (https://containers.dev/) and what are the advantages, as I see a lot of overlap
Workshop looks to do a really nice job removing a lot of the friction users feel when trying to get off the ground in starting their AI projects. Can you share any planned future features or improvements on the Workshop roadmap?
Can you share what I can do if I need extra configurations/settings/tools that are specific for my use case that I don’t have or cannot find in an SDK from the store?
I think I missed answer for this question.
I don’t think the question was asked.
I am not sure it was answered either there was talk about other developer environments not sure it related to this, but i wanted to understand the pro and cons in relation to devcontainer and where workshop would fit in or is the better option.
Also need to understand if the SDK store can be hosted in an air gapped environment to
I have similar question - why this one in compare to others even if difference will be in future development.
Indeed, there’s some. Technical writer for the project here, my take follows below.
The first notable difference comes around Features vs SDKs. While features do enable arguably comparable publisher-led extensibility and distribution, they seem to have an create/start/install focus (hooks, install.sh). Workshop SDKs and their lifecycle hooks address multiple phases of a wider container lifecycle, including a durability goal, i.e. surviving environment refresh/upgrade/rollback, which is in itself a major part of what Workshop is. There’s also a dedicated authoring tool, sdkcraft, with structured build/publish steps.
The other one is that devcontainers tend to start leaking underlying Docker entities sooner than later, leaving the user to deal with these on their own. Workshop YAML definitions aim to stay at declarative intent level; mundane LXD details are handled by the workshopd daemon. To access host resources, in particular, you’ll need to set up the devcontainer the way you would scaffold a docker run command, option after option. Workshop does away with that by adopting a clearly defined interface surface. Also, Docker containers don’t always map nicely to the needs of a dev environment (layering, entrypoints, etc); Workshop uses system-level containers and provides project directory auto-mounting, ZFS snapshots, transactional updates and rollback.
One clear benefit for devcontainers is the level of adoption/support, for obvious reasons.
For more details (this aims at vanilla Docker, though): https://documentation.ubuntu.com/canonical-workshop/latest/explanation/sdks/sdk-vs-dockerfile/
