Orbital home page
Go back

New start script, and changes to default config

Date

    We’ve made some small changes on how to get Orbital running. We’ve also added a new config variable to centralize where Orbital stores all it’s internal files. You should add this config variable to your own deployments before 0.37 is released.

    ​
    New way to start Orbital - start.sh

    We’ve updated the way people get started on Orbital - replacing our docker-compose.yml with a bash script.

    If you head over to orbitalhq.com, you’ll notice that we’re now asking people to start by curling:

    curl -sSL https://start.orbitalhq.com/start.sh | bash

    You can view the bash script - it’s still running the same docker-compose.yml, but we’ve just added some scripting to make the experience a bit better.

    ​
    What do I need to do?

    There’s very little that’s changed.

    You should add --vyne.app.data.path=/a/path/for/your/config to your config. It’s safe to do this now, before 0.37.0 is released.

    It’s also safe not to do this at all, and Orbital will work with reasonable defaults. But, our new preferred config includes setting this property.

    ​
    What we changed:

    • By default, the app now launches with user permissions, rather than root
    • All app data (license files, temporary write queues, lucene search indices) are now written to the same, configurable directory (--vyne.app.data.path)
    • Docker Volume directories are created before docker starts

    ​
    Why we did this - the pains of Docker Compose

    We still ❤️ Docker Compose - it’s our preferred way for people to start the stack. But, we hit issues that made the experience unpleasant for developers…

    ​
    File permissions

    When you’re working with Orbital, we expect you’ll do some stuff inside the browser, and other stuff inside your IDE.

    However, if Docker creates the directories you’re using - even if your docker container is running with a non-root user, then you can end up with file permissions errors. You - the user - lack the permissions to edit the files that get created.

    The start.sh fixes this by simply creating the directories before docker launches,

    ​
    User permissions

    Telling Docker Compose to launch in a non-root user is slightly trickier than you’d expect. It’s not hard, but you can’t say “run with my account”, you have to say “run with this account”.

    The idiomatic way to address this is:

    services:

   orbital:
      image: orbitalhq/orbital:${ORBITAL_VERSION:-next}
      user: "${UID}:${GID}"

    And then have a .env file that defines those variables:

    UID=1000
GID=1000

    This isn’t difficult, but it’s awkward for a user to just get started. So, the script handles this for you.

    ​
    Networking

    Orbital is an integration platform, so when we ship demos or test stacks, we need things to integrate.

    We solved that by building Nebula to deploy local environments. However, Nebula deploys other docker containers - and docker-launching-docker varies between OS’s. That meant our docker-compose.yml is OS-specific. We built tools to detect and try to serve the correct docker-compose.yml, but it’s clumsy if you’re running from the command line.

    Our script detects which OS you’re running on, and downloads the correct docker-compose file for you.

    ​
    Summary

    That it! The new launcher script is live now, and config variables are shipping now in next and will be part of the 0.37 release.

    Happy integrating.