Jumppad enables the creation and configuration of lightweight, reproducible, and portable environments as code.
Jumppad Description
Primary Purpose:
Jumppad is a tool designed to create modern cloud-native development environments. It utilizes its own configuration language to build reproducible and portable environments as code, supporting platforms such as Docker, Kubernetes, and Nomad.
Key Features:
Cross-platform support for Docker, Kubernetes, Nomad, and experimental Podman integration.
Enables the creation of reproducible environments as code, ensuring consistency across different setups.
Integrates seamlessly with existing tools, enhancing workflow efficiency.
Facilitates the development of interactive documentation and redistributable demo environments.
Audience & Benefit:
Ideal for developers, DevOps engineers, and teams focused on cloud-native applications. Jumppad streamlines workflows by providing consistent environments, simplifies sharing of interactive content, and supports modern infrastructure needs.
README
jumppad
Jumppad is a tool for building modern cloud native development environments. Using the Jumppad configuration language you can create OCI containers, Nomad/Kubernetes clusters and more.
Kind of, but more about local environments rather than infrastructure
Why not use Docker Compose?
Docker Compose is one of our favourite tools but we found it does not manage dependencies particulary well. Compose also works on a really low level of abstraction. Jumppad addresses these missing features.
Is Jumppad just for Docker?
No, Jumppad is designed to work with Docker, Podman, Raw binaries, etc. At present we only have a Driver for Docker and Podman, but others are on our Roadmap.
Can I use Jumppad for anything other than Dev environments?
Yes, Jumppad can be used to create interactive documentation for your applications and redistributable demo environments to show off your tool or product.
Example Jumppad Config
The following snippets are examples of things you can build with Jumppad, for more detailed examples please see the Blueprints repo https://github.com/shipyard-run/blueprints
Podman support is experimental and at present many features such as Kubernetes clusters do not work with rootless podman and require root access.
Enable the podman socket
Jumppad uses podman's API, which is compatible with the Docker Enginer API. To enable this, you need to run the podman socket as a group that your user has access to. The following example uses the docker group:
sudo sed '/^SocketMode=.*/a SocketGroup=docker' -i /lib/systemd/system/podman.socket
Configure dnsmasq for external name server resolution or external network connections will not work
.
Contributing
We love contributions to the project, to contribute, first ensure that there is an issue and that it has been acknowledged by one of the maintainers of the project. Ensuring an issue exists and has been acknowledged ensures that the work you are about to submit will not be rejected due to specifications or duplicate work.
Once an issue exists, you can modify the code and raise a PR against this repo. We are working on increasing code coverage, please ensure that your work has at least 80% test coverage before submitting.
Testing
The project has two types of tests, pure code Unit tests and Functional tests, which apply real blueprints to a locally-running Docker engine and test output.
Unit tests
To run the unit tests you can use the make recipe make test_unit this runs the go test and excludes the functional tests.
jumppad on ī master via š¹ v1.13.5 on š³ v19.03.5 ()
ā make test_unit
go test -v -race github.com/jumppad-labs/jumppad github.com/jumppad-labs/jumppad/cmd github.com/jumppad-labs/jumppad/pkg/clients github.com/jumppad-labs/jumppad/pkg/clients/mocks github.com/jumppad-labs/jumppad/pkg/config github.com/jumppad-labs/jumppad/pkg/providers github.com/jumppad-labs/jumppad/pkg/jumppad github.com/jumppad-labs/jumppad/pkg/utils
testing: warning: no tests to run
PASS
ok github.com/jumppad-labs/jumppad (cached) [no tests to run]
=== RUN TestSetsEnvVar
--- PASS: TestSetsEnvVar (0.00s)
=== RUN TestArgIsLocalRelativeFolder
--- PASS: TestArgIsLocalRelativeFolder (0.00s)
=== RUN TestArgIsLocalAbsFolder
--- PASS: TestArgIsLocalAbsFolder (0.00s)
=== RUN TestArgIsFolderNotExists
--- PASS: TestArgIsFolderNotExists (0.00s)
=== RUN TestArgIsNotFolder
--- PASS: TestArgIsNotFolder (0.00s)
=== RUN TestArgIsBlueprintFolder
--- PASS: TestArgIsBlueprintFolder (0.00s)
=== RUN TestArgIsNotBlueprintFolder
Functional tests
To run the functional tests ensure that Docker is running in your environment then run make test_functional. functional tests are executed with GoDog cucumber test runner for Go. Note: These tests execute real blueprints and can a few minutes to run.
ā make test_functional
cd ./functional_tests && go test -v ./...
Feature: Docmentation
In order to test the documentation feature
something
something
Scenario: Documentation # features/documentaion.feature:6
Given the config "./test_fixtures/docs" # main_test.go:77 -> theConfig
2020-02-08T17:03:25.269Z [INFO] Creating Network: ref=wan
2020-02-08T17:03:40.312Z [INFO] Creating Documentation: ref=docs
2020-02-08T17:03:40.312Z [INFO] Creating Container: ref=docs
2020-02-08T17:03:40.490Z [DEBUG] Attaching container to network: ref=docs network=wan
2020-02-08T17:03:41.187Z [INFO] Creating Container: ref=terminal
2020-02-08T17:03:41.271Z [DEBUG] Attaching container to network: ref=terminal network=wan
When I run apply # main_test.go:111 -> iRunApply
Then there should be 1 network called "wan" # main_test.go:149 -> thereShouldBe1NetworkCalled
And there should be 1 container running called "docs.docs.jumppad.dev" # main_test.go:115 -> thereShouldBeContainerRunningCalled
And a call to "http://localhost:8080/" should result in status 200 #
# ...
3 scenarios (3 passed)
16 steps (16 passed)
3m6.79621s
testing: warning: no tests to run
PASS
Creating a release
To create a release tag a commit git tag and push this to GitHub git push origin GitHub actions will build and create the release.