Normally, Ruckstack is used to package and connect your services, databases, etc. into a single installable for on-site customers. But, that same packaging logic can also be used to collect up everything you need for your development environment installations.
Ask yourself this: What does it take for a new developer to start working on a server-based application? How much time does your experienced developers spend reconfiguring and maintaining their local environments as they work across different areas of the code?
Do they need to install and configure databases? Messaging systems? Do they need to install and configure separate build toolkits for frontend and backend code? What does it take to run parts of the application in their debugger?
Even if you don’t use Ruckstack for deploying your software to production, it can still ease your development process.
Packaging Your Full Stack
The first problem Ruckstack solves for a development team is streamlining what it takes to get your entire application stack running on their local machines. By setting up a Ruckstack build in your build server, you get a single installable file containing everything needed to run your software.
Configuring your application for Ruckstack starts with a ruckstack.yaml configuration file. For many people, the dockerfile format is the easiest because it requires only standard dockerfiles. But, if you already leverage Helm or Kubernetes, you can also use your existing configurations.
If you would like to follow along without going through the work of Ruckstack-izing your existing application, you can:
- Run “
ruckstack init --template example” to create a sample Ruckstack project to play with.
- Take a look at the generated ruckstack.yaml to get an idea of what it will take to configure your application
- Run “
ruckstack build” to create the installer file
- This is something you will want to add to your buildserver
- Run the new installer file
- Start the server with “INSTALL_DIR/bin/example-manager start”
- See the running server at http://localhost
Plugging into the Packaged Services
While easy installation of pre-packaged code is great, what your team really needs is a way to quickly and efficiently develop and debug new code.
You already have your preferred tools for quickly reloading and debugging your code. Maybe you have a Java app you run from your IDE. Maybe you use
nodaemon with NodeJS. Whatever you use, you keep doing you.
What makes that easier with your Ruckstack’ed install is that your database and other external services are already built and up and running for you. You no longer need to build, configure, or figure out how to run all the supporting services. Instead, you start your code in your development environment of choice, and point it to the pre-build, pre-packaged, and pre-configured services it needs. NOTE: by default, the packaged services are not exposed outside the internal system. Use the “proxy” settings in your ruckstack.yaml file to make needed services available to your externally running applications.
The final advantage Ruckstack gives you is the ability to make those locally-running services act like they are running inside your packaged system. This avoids troublesome backend vs. frontend hostname differences for your browser to deal with, and allows cross-service communication to continue to run with no reconfiguration needed.
Ruckstack supports this by providing an easy way to transparently “reroute” traffic from specific pre-packaged services to your development version.
Before you can reroute traffic, you need to set your server into “dev mode” with “/path/to/your/manager dev enable”. If you are using the example template, the manager is called “example-manager”.
bash$ sudo bin/example-manager dev enable
WARNING: 'Development Mode' is designed to help with the development and testing of this system.
WARNING: It is NOT intended for production systems and may impact performance and/or security.
Enable Development Mode: [y|N]
Development mode enabled
Once dev mode is enabled, you can “reroute” calls within your application to a server running outside the packaged system.
bash$ bin/example-manager dev reroute --service backend --target-host localhost --target-port 8080
Requests for service ‘backend’ will now be proxied to http://localhost:8080
If you are following along with the example application, hitting http://localhost will now give you a “Gateway Timeout” popup because the request to the backend service is being proxied to a currently non-existent service.
You can start the backend service locally from the “backend” directory of the example project with:
bash$ export POSTGRES_HOST=<CONFIGURED EXTERNAL IP>
bash$ export POSTGRES_PASSWORD="$(sudo bin/example-manager secure-config-data show --name postgresql --key postgresql-password)"
bash$ npm install
bash$ nodejs server.js
Running on http://0.0.0.0:8080
Notes table created
Notice how our backend project has some configurable settings to point the database at the packaged database using environment variables. It’s up to you to determine what needs to be configured and how to do it based on your own needs.
Now, when you hit http://localhost the app loads like normal — but the packaged frontend service is actually talking to your separately running backend server. You can see that because your local service logs Requested GET /api/notes.
When you are done developing your service, you can remove the reroute with:
bash$ bin/example-manager dev remove-route --service backend
Requests for service ‘backend’ will now be served by the packaged service.
The example Ruckstack project uses a NodeJS service, but the same pattern applies to any technology you use:
- Download a pre-packaged, Ruckstack-ized file containing your entire application stack
- Start your code in your development environment of choice, pulling data from the pre-packaged services as needed
- Reroute requests in your packaged system to be handled by your in-development server
Featured image via Pixabay.