A workspace-in-a-container project.
workspace
is a portable environment in a Docker container, powered by my work and personal dotfiles setup. You can test it straight away:
docker run -it --name=workspace pirafrank/workspace:bundle
Important : Renamed repository!
This repository is was previously named dotfiles
and has been renamed to workspace
. Dotfiles that once were part of this repo have moved to their own. Now they are here as a submodule.
I went this way to have the chance to further evolve the workspace project away from dotfiles, keeping both consistent commit history and releases made until today. On the other hand, the dotfiles
repo has a rewritten commit history.
- Ubuntu 20.04-based
zsh
+ zprezto as default shell- dotfiles
- vim as IDE
- cloud clients and tools
- Java + mvn
- node.js
- Python 3
- Golang
- Rust
- Ruby
- various utils
- optional Docker CLI client
- support for different env versions
- ...and more.
Docker images work anywhere Docker images run, from your PC to Kubernetes, to CaaS services.
While almost all scripts and configurations in this repo will also work on non-Debian distros, setup.sh
script in root is designed for the Debian-based ones. That said, the only differences shoud rely only on a few package and binary names.
macOS + macports is partially supported. I try to make workspaces
and setups
scripts work there too, yet macOS is not my daily driver anymore and the Apple Silicon transition adds spice to the receipe.
Choose one of the options below:
- run the containerized workspace (Docker required)
- run the full
setup.sh
script on a vanilla environment (e.g. a new VPS install) - setup specific features (Java+mvn, node.js, etc.) using the scripts in
setups
andworkspaces
dirs. Those scripts are also used to build the workspace Docker images.
You can run the workspace-in-a-container in many occasions.
- easy and fast setup of CLI environment e.g. in a VPS
- Works in CaaS services like Azure Container Instances and Blink Build
- great for already-configure, fast, ephimeral dev environment
- you name it...
Please check the workspace-in-a-container 'Usage scenarios' section for further info.
Debian-based distros only.
A full setup involves programs installation of programs, their dependencies, download of dotfiles and creation of symlinks. It is meant to setup a vanilla environment. I keep setup.sh
aligned with the Dockerfile
used to build the Docker workspace baseimage. The setup comes in two flavors, with and without user creation:
curl -sSL https://github.com/pirafrank/workspace/raw/main/create_user.sh -o create_user.sh && chmod +x create_user.sh
curl -sSL https://github.com/pirafrank/workspace/raw/main/setup.sh -o setup.sh && chmod +x setup.sh
./create_user.sh
./setup.sh
Run the one that best fits your needs. Remember to always check the content of scripts you're about to execute before running them!
Setup scripts in setups
and workspaces
dirs are meant to be executed manually on Linux or macOS, or to build Docker Image workspaces (read below). They assume ~/dotfiles
exists. If you have dotfiles in another dir, please symlink it to ~/dotfiles
.
Core setup uses zsh and zprezto. Files for oh-my-zsh config are available, but I don't use/update them anymore.
~/.zsh_custom
is automatically sourced if it exists, and ~/bin2
is automatically added to $PATH
. Both are not part of the repo and can be used to add your-own or machine-specific customizations and other executables.
That's all, there is no real how-to actually. For more info just look at the code.
The main focus is to make Workspace a great workspace-in-a-container setup.
The aim is to create a disposable development environment taking advantage of Docker. Images are publicly available on Docker Hub in various flavors. They are:
pirafrank/workspace
: base image on which the others are based on. It contains dotfiles, various CLI utils and shell setuppirafrank/workspace:bundle
: bundle of the ones below. Useworkspace_version
inside the container to know about what's bundled.
Dockerfiles available to build:
pirafrank/workspace:java
: Java +mvn
pirafrank/workspace:node
:nvm
+ node.jspirafrank/workspace:python3
:pyenv
+ Python 3pirafrank/workspace:ruby
:rvm
+ Rubypirafrank/workspace:rust
: latest Rust version and its toolchainpirafrank/workspace:go
: Golang workspace
All workspaces setups are in userspace.
The following apply:
- Docker image builds are made from
main
branch only. Builds are triggered only if changes are made to source files (e.g. it skips changes to pipeline files, README, etc.). - Only after a successful pipeline run, builds are pushed to docker registries and lightweight tags are added to the repository. Those tags have format:
YYYYMMDD.CommitHash
. - After a meaniful set of changes are added to repository, I tag one of those lightweight-tagged commits with a signed annotated one using semantic versioning format.
- By the way, although versioning plays its part in pulling a specific version,
latest
andbundle
tags are meant to be used as the latest stable images.
Workspace images now ship with openssh-server, so you can deploy your workspace on a CaaS provider and SSH to it.
By default the openssh-server won't start and an interactive shell will launch, this means that if you won't start the workspace from an interactive shell it will exit immediately!
If you deploy on a CaaS and want to leverage openssh-server, just pass these two ENV VARs upon container start:
SSH_SERVER
, any value is ok (e.g. 'true'), just don't leave it null;SSH_PUBKEYS
, it holds the pubkey you want to use to connect via SSH (only one pubkey supported atm).
It listens to 0.0.0.0:2222
.
For example:
docker run -it --rm \
-p "2222:2222" \
-e SSH_SERVER=true -e SSH_PUBKEYS="ssh-ed25519 AAAA... francesco@work" \
pirafrank/workspace:latest
if you have multiple SSH pub keys:
# from file
export SSHKEYS=`cat file_with_many_keys`
# from URL
export SSHKEYS=`curl -sSL some.url/with/keys/sshkeys`
# then in command above
... -e SSH_SERVER=true -e SSH_PUBKEYS="${SSHKEYS}" ...
or via run script:
bash run-workspace.sh latest '--rm -e SSH_SERVER=true -e SSH_PUBKEYS="ssh-ed25519 AAAA... francesco@work"'
Check pre_start.zsh
and start.sh
scripts for further info.
You can run your workspace in many ways. Check the examples in scenarios
dir.
Simple use case start to run it locally, e.g. you need tools and don't want to install them on your PC.
Pleas check the readme here.
General purpose, openssh-server is a great helper here.
For the sake of brevity, please check files in the scenarios/k8s
dir.
Azure Container Instances provide a great environment to run workspace on-the-go and start/stop when you need it.
Please check the full readme here.
Coming soon...
Build is a new service being built by the guys behind Blink Shell, the best SSH and mosh client for iOS and iPadOS. It's currently in beta and allows you to SSH into any container publicly available without taking care of the underlying infrastructure, network or firewall. And it's fully integrated in Blink Shell. I have started tinkering with it and I have to say it's a great match with my workspace for a portable dev environment!
Please check the full readme here.
Coming soon...
Build and run images on Docker locally.
Run ./build.sh all
to build all images.
Add anything you want to exec right before container launch to pre_start.zsh
.
You can also change the commands executed at startup by editing the start.sh
script.
Use run_workspace.sh
to do so. Clone the repo or just download the script.
The script will default to pirafrank/workspace
images, you just need to specify the tag name.
For example:
# to run the baseimage
./run-workspace.sh latest
# or to run the java11 one
./run-workspace.sh java11
# or to run it as a disposable container
./run-workspace.sh java11 --rm
# or to name it
./run-workspace.sh java11 '--name somename --rm'
Code in this repo is given away for free, as-is and with NO WARRANTY as per the MIT license.
By the way, if something really blows your mind, I'll be happy if you get in touch with me. I always appreciated feedback!
Enjoy!