Ideas
- Web GUI with options to show where to deploy - location, which VM to deploy to - different VM kinds and sizes, which Redis version to deploy
- Web GUI will be served as a static website, using a CDN or some simple web server
- Data shown in the GUI will be dynamic and will come from the backend API, a separate server
- Use Digital Ocean tokens to interact with Digital Ocean
- Use prebuilt Digital Ocean machine images to deploy Redis
Redis deployment
- Install Redis and have a systemd unit to run it
- Configure Redis with a strong (long, complex, random) password
- Configure Redis to serve at a random port and expose it too. Random port because it's on the Internet
Web GUI
- Develop a nice UI with good CSS. Checkout tailwind and similar CSS frameworks.
- Tailwind - https://play.tailwindcss.com/nhc2VyEDK5
- JS - React? Vue? Something else? Keep it minimal, use existing components, code and libraries as much as possible, with minimal code written to codify the site
- Create mockup first before building the site
Machine images
- Use packer to build machine images for digital ocean https://www.packer.io/docs/builders/digitalocean
Server
- APIs to get location details and droplet details from Digital Ocean
Configuring Redis as part of the deployment
- We can configure using something like
user_data
- cloud-config file or bash script - We can configure things like - a dynamic port number, a random password. Both of these can be generated as part of the user data code or injected into the user data code. If it's injected, the generation has to take place outside prior to machine creation and in that case we would know all the values after machine creation. But if it's not injected but instead generated as part of user data code - is it possible to retrieve it after machine creation? Because we would need the port number and password for connecting to the Redis for the first time at least, till we change the password to something else manually or automatically using something like Hashicorp Vault
Alternative ideas
-
No backend server, fully front end application, interacting with Digital Ocean APIs directly using the token from the user and keeping it all in the local. Possible? What are the pros and cons? But yeah, we need to keep all the state in the web app's local storage and show progress etc. If everything is done using Digital Ocean HTTP APIs, it should be possible. If we need some other feature from a separate backend API, then we would have to create the backend API, or else it's just kind of like a proxy to Digital Ocean, but yeah, the backend can maintain state in database, for example the Digital Ocean token and any preferences etc, but that's also possible in the front end, but yeah, it has to be kept securely in the front end local storage, if some other app accesses it then it would be compromised
-
No backend server, no web app or front end app or any kind of GUI, only CLI / bash script to deploy the whole thing with a config file or in an interactive manner. For example, interaction would look like "Which cloud?" and it would support only Digital Ocean for now and then ask "Which size droplet?" and show different options and then ask specific questions about the Redis configuration and get input and then get the Digital Ocean API token in a masked password format or through environment variable and that's it! :D Show progress bar for status etc