Open joepavitt opened 3 months ago
Lots of issues with wildcard DNS. Larger orgs do not like the vulnerability it poses and it can take a month or more to get approval just for DNS, delaying evaluation.
Customers/prospects that had an issue:
https://app-eu1.hubspot.com/contacts/26586079/record/0-2/7845572820 https://app-eu1.hubspot.com/contacts/26586079/record/0-2/9080239048 https://app-eu1.hubspot.com/contacts/26586079/record/0-2/11792021958
The wildcard DNS requirement is a fundamental design point of the Docker & Kubernetes implementation, it can not be removed.
On Kubernetes if the user is prepared to use External DNS then the system can create each DNS entry individually, but this requires granting K8s the ability to dynamically update the DNS which is likely to be even more unwanted than a wildcard entry.
One pain point for both docker/k8s is the need to create the config files needed to run the platform. We should provide interactive scripts to generate the files. Have added items for both to the tasks above.
We have a script from the AWS/Digtial Ocean build to build the config file for docker, we should be able to reuse that
https://github.com/FlowFuse/digital-ocean-droplet/blob/main/files/opt/flowforge/first-login.sh
How technical are we seeing our customers that install FF locally? Is there first question here that a user is going to know the answer to: "What operating system are you running?"
For manufacturing clients, are they even going to know k8s/docker as assets? We're recently seen the challenges of getting FF running in Windows given the requirement for Docker Desktop too?
Regarding the guided script you mentioned @hardillb - would that be guiding users through https://flowfuse.com/docs/install/docker/#configuring-flowfuse?
Yes, it does the search/replace for the domain and email settings in the flowforge.yml and the docker-compose.yml files
Chatting with @ppawlowski about what questions user's are likely to have:
What other considerations do they need to have when deciding with of the four paths (Docket, k8s, Do, Docker on AWS) that a user would need to know?
@joepavitt Any updates on this issue? I'd love to understand what's being done to have a bigger install base for FlowFuse
@robmarcer is going to provide a flow chart that details the general customer workflow we get, which roles we're talking to, and the path we find for installation/configuration of FF
@ppawlowski as part of your exercise here, could you produce a simple checklist of things that a user needs to actually setup/install, in order to have an instance of FlowFuse running please? e.g. DNS Records, SMTP Server for e-mail notifications, TLS configuration
Chatting with Piotr - "Quickstart Guide" option on the install
page, "Docker Compose, 2/3 commands and you are done"
e.g. https://doc.traefik.io/traefik/getting-started/quick-start/
Description
May be some overlap with #3839
This Epic is to capture hurdles and areas for improvement for the onboarding process for FlowFuse Self-Hosted.
Review
As part of this exercise, we will be conducting reviews of the full installation and setup of FlowFuse in self-hosted environments.
For each scenario it is important to have a blank slate, install FlowFuse and setup FlowFuse with the relevant settings such that it is possible to run an instance of Node-RED in FlowFuse.
Any friction, concerns and areas for improvement should then be documented in the following tasks lists which are broken into two sections:
Installation
The process of retrieving a copy of FlowFuse and running in a particular environment. Ideally, this would be a single line install in some capacity. This can also cover improvements for onboarding resources like documentation/videos.
Setup & Configuration
Having an available instance of FlowFuse, this is a review/assessment of the setup steps required to then having a running instance of Node-RED.
Which customers would this be available to
Self-Hosted