mirror of
https://github.com/bluxmit/alnoda-workspaces.git
synced 2024-09-30 09:16:14 +13:00
186 lines
12 KiB
Markdown
186 lines
12 KiB
Markdown
# Workspaces in docker
|
|
|
|
### Contents
|
|
|
|
* [About](#about)
|
|
* [Quickstart](#quickstart)
|
|
* [Available workspaces](#available-workspaces)
|
|
* [Why dev environmet in docker](#why-dev-environmet-in-docker)
|
|
* [Workspaces-in-docker vs. cloud IDE](#workspaces-in-docker-vs.-cloud-ide)
|
|
* [Workspaces-in-docker vs. other docker workspaces](#workspaces-in-docker-vs.-other-docker-workspaces)
|
|
* [Workspaces-in-docker principles](#workspaces-in-docker-principles)
|
|
* [Publications](#publications)
|
|
* [Feedback and contribution](#feedback-an-contribution)
|
|
|
|
|
|
## About
|
|
|
|
Workspaces make development, experiments and workloads isolated in their own dockerized environments,
|
|
enable working directly inside the running docker containers, and help managing multiple projects easily.
|
|
|
|
Workspaces include tools and software that make working inside docker nearly as convenient as working
|
|
directly in local environment.
|
|
|
|
![Workspaces are amazing!](./workspaces/workspace-in-docker/img/workspace-demo.gif)
|
|
|
|
Workspace is not only a development environment. Some workspaces include lots of tools and packages, that otherwise would
|
|
take lots of time to set up.
|
|
|
|
Workspaces are familar docker images and containers. Working with workspaces will not require learning any new tools,
|
|
only will help to improve docker skills.
|
|
|
|
Workspaces allow moving complete environments between machinnes and cloud servers as easy as 2 clicks. With workspaces you can
|
|
actually have 2 develpment machines, and sync them very easily. You can even work in the vary same workspace on your Mac laptop
|
|
and Windows PC. And then you move the complete development or runtime environment to a cloud Linux server in under 1 minute.
|
|
|
|
Workspaces are great for collaboration. Imagine being able to share with your peer not only the codebase, but also to the whole environment
|
|
with all the dependencies and config files.
|
|
|
|
Workspaces make containerization and deployment as easy as possible, without the need of building docker
|
|
images again. We love containers for their ability to run on production environment exactly the same way
|
|
they are running on "your laptop". We already run a lot in containers. Why not build our apps in containers as well?
|
|
Then we can simply skip the extra step of building images again and again.
|
|
|
|
Workspaces can be used as true Linux terminals. Anywhere. On any system. In fact, workspaces include lots of tools that
|
|
make woking in terminal a pleasure.
|
|
|
|
<p align="center">
|
|
<img src="./workspaces/ubuntu-workspace/img/ubuntu-workspace.gif" alt="Ubuntu workspace" width="750">
|
|
</p>
|
|
|
|
Workspaces are great to preserve sometnig that works. Imagin you have made an MVP. Something actually working. It is not enough just to
|
|
commit the code. Save the complete workspace! With all environments, dependencies and configurations. Later it might save you a lot of time.
|
|
|
|
Workspaces are completely open-source and include only popular wide-spread open-source tools. No proprietary software.
|
|
|
|
## Quickstart
|
|
|
|
Launching new workspace is as easy as
|
|
|
|
```sh
|
|
docker run --name space-1 -d -p 8020-8030:8020-8030 alnoda/workspace-in-docker
|
|
```
|
|
|
|
that is it! Open workspace UI ***[http://localhost:8020](http://localhost:8020)***
|
|
|
|
or enter workspace terminal
|
|
```sh
|
|
docker exec -it space-1 /bin/zsh
|
|
```
|
|
|
|
## Available workspaces
|
|
|
|
1. [`Ubuntu-workspace`](./workspaces/ubuntu-workspace/README.md) - is an attempt to use docker as a light-weight Virtual Machine. It
|
|
provides isolation of environments, but uses less resources than VMs. Ubuntu-workspace allows to start multiple processes inside the
|
|
same docker container, has docker-in-docker, Python and Node.js, and a collection of common applications such as text editors,
|
|
git, supervisord, z-shell etc. Ubuntu-workspace exposes browser-based terminal, and can be used on both local and remote server providing the same experience.
|
|
When it runs on the remote server, access can be restricted with a password.
|
|
|
|
2. [`Base-Workspace`](./workspaces/base-workspace/README.md) - docker as a light-weight Virtual Machine with batteries included,
|
|
designed to be used entirely through browser-based interfaces. Base-Workspace has its own UI, and a collection of applications for more
|
|
convenient work, such as File Browser to easily exchange files and folders with workspace, Cronicle - advanced job scheduler with great UI,
|
|
MkDocs for documentation of the workspace and projects. This workspace includes all the features of the *Ubuntu-workspace*.
|
|
|
|
3. [`Workspace-in-docker`](./workspaces/workspace-in-docker/README.md) - has all the features of the *Base-Workspace*, and in addition -
|
|
a powerful browser-based version of Visual Studio Code. This workspace allows complete isolation of many IT-related projects, such as
|
|
software development, devops, QA, data analysis, data engineering, data science and other. Workspace can be used as local development environment,
|
|
as well as remote, when started on the cloud server, and can be secured with password. Workspace-in-docker allows to completely isolate and switch easily
|
|
between projects that involve multiple programming languages, different clouds, k8s clusters and have system dependencies. Withou this workspace
|
|
swithing between such complex environments would require multiple actions and can be tedious work. Workspace-in-docker is great for collaborative work,
|
|
can be easily shared, moved to any cloud server, backed up, has versions and can be easily extended and customized. Can be used as build, test or even
|
|
runtime environment.
|
|
|
|
4. [`Codeserver-Workspace`](./workspaces/codeserver-workspace/README.md) - alternative workspace to the `workspace-in-docker`. It has all the features ot the latter, except for the
|
|
different implementation of the Visual Studio Code. While `workspace-in-docker` has [Eclipse Theia IDE](https://theia-ide.org/), Codeserver-Workspace
|
|
includes [Codeserver](https://github.com/cdr/code-server) instead.
|
|
|
|
5. [`MkDocs-MagicSpace`](./workspaces/mkdocs-magicspace/README.md) - an all-in-one tool, carefully crafted to develop, build and serve awesome static websites, for the purpose
|
|
of documentation, tutorials, and training.
|
|
|
|
|
|
## Why dev environmet in docker
|
|
|
|
Have your ever participated in several software (sysops, analytics, BI, data science, ML) projects at the same time?
|
|
And each of them having different environments (dev, stage, prod), cloud config file, k8s cluster, ansible secret,
|
|
terraform workspace... Managing such a collection of environments is so much easier
|
|
if everything is packaged inside a docker container, that you can start and stop by one single command.
|
|
|
|
There are lots of limitations compared to local environment. For example, you will have to work only with WEB-based tools - this limits your choices
|
|
and might not include your favourite shiny IDE, on which you spent so many months to configure and learn. Also a web-based IDE is always slower
|
|
than its native alternative, and probably not as feature-rich.
|
|
|
|
But the benefits of isolating everything related to the specific project in one docker image that can be saved, versioned, moved to another machine,
|
|
deployed on cloud server or shared with anyone, by far outweighs those limitations.
|
|
|
|
*Workspaces promote non-canonical way of using docker, taking advantage of features, we don't often use.*
|
|
|
|
We already run a lot in containers. Why not build our apps in containers as well?
|
|
Workspace encapsulates nicely project or experiment with all the dependencies, helping to avoid situation when one environment can affect another.
|
|
|
|
> Docker is a great tool to bundle together all the things that are related to the same project. It is light-weight and you can start multiple workspaces.
|
|
|
|
We often over-engineer and waste time on something that we could do better. If we do something on our local machines, it becomes isolated, non-transferrable
|
|
and not shareable. If we do the same work inside a running docker container, we can commit it to the new image and share with peers or run
|
|
on cloud servers, and this is all - just 3 commands in terminal.
|
|
|
|
## Workspaces-in-docker vs. cloud IDE
|
|
|
|
There are other options that provide isolated environments and let work in cloud directly.
|
|
Cloud9, CodeAnywhere, GitPod, GroomIDE you name it - are awesome and affordable services, that are even easier to use than workspaces-in-docker.
|
|
But workspaces-in-docker have some serious advantages:
|
|
|
|
- workspaces-in-docker are transferrable, they can be used on both local machine as well as in cloud,
|
|
being easily moved back and forth. You might not always have perfect internet, and running workspace on the local machine can be more convenient.
|
|
And you can always move workspace to a powerfule server in cloud within couple minutes.
|
|
|
|
- workspaces-in-docker are more configurable. Tey are open-source docker images after all. Create new image from the workspace image,
|
|
and you will have highly customized personal workspace.
|
|
|
|
Workspaces-in-docker is a middle ground between two extremes: the unwieldy static local environment - unseparable from your laptop,
|
|
and euphemeral cloud environments that are much less versatile.
|
|
|
|
## Workspaces-in-docker vs. other docker workspaces
|
|
|
|
The idea of development in docker is not new at all. In fact there are other projects in GitHub
|
|
that encourage users to work directly in the docker containers.
|
|
|
|
On the left side of the spectrum, there are WEB-based IDE, each of them having their own docker images.
|
|
|
|
On the right side there exist over-packed docker images for particular use-cases, that include way too many tools than probably needed.
|
|
|
|
Workspaces-in-docker take the niche in the middle. Instead of building one heavy unwieldy image that focuses on one specific use-case,
|
|
we create a "constructor" stack of images build on top of each other for better control and ease of customization.
|
|
|
|
And we take security seriously. Workspaces-in-docker by default run under non-root user. Of course you can run or enter workspace as root too.
|
|
This makes it secure to share with peers, or deploy production ready applications directly as workspace container.
|
|
|
|
## Workspaces-in-docker principles
|
|
|
|
When developing our dockerized workspaces, we try to set and follow some rules:
|
|
|
|
- worksapces should be easy to use and solve real problems
|
|
- start with generic workspaces, suitable for common needs
|
|
- more specific workspaces should be built on top of generic workspaces
|
|
- rather than building ubder-workspace for all needs, workspaces should branch out from ther generic workspace and focus on specific needs
|
|
- workspaces should be well-tested and documented
|
|
- workspaces should include only open source tools
|
|
- workspaces don't include as much stuff as possible, workspace should have minimal needed set of tools
|
|
- include in the workspace only tools that share processes and data. Reverse proxy, load balanncers,
|
|
databases, server resource monitors should not be the part of the workspace. Instead they should be integrated with
|
|
workspace in docker compose.
|
|
|
|
## Publications
|
|
|
|
- [The way I use Docker as interactive environment for tries and experiments](https://medium.com/@bluxmit/the-way-i-use-docker-as-interactive-environment-for-tries-and-experiments-52ac06c0ec69)
|
|
- [Docker as a lightweight VM - docker image that you can use as VM substitute](https://medium.com/@bluxmit/docker-as-a-lightweight-vm-docker-image-that-you-can-use-as-vm-substitute-164032e4ed0b)
|
|
|
|
## Feedback and contribution
|
|
|
|
Workspaces in docker helped me to manage multiple projects in different clouds and k8s clusters. They made my work so much easier,
|
|
and I hope they can be useful for other people too.
|
|
|
|
I will highly appreciate any suggestions, ideas for improvements, contribution or any other form of collaboration.
|
|
Send me an email bluxmit@gmail.com
|
|
|
|
|
|
|