Installation improvements 0.1.4

[Brent Moran]

Hello!

I want to provide an opportunity for any feedback on the new installation improvements plan for 0.1.4

• Main 'try-it-out' installation path will be the unified docker image
• includes webservice and internal database
• can be run with single 'docker run' command
• doesn't include reverse proxy
• We'll have a section of recommendations for making the unified docker image setup prod-ready
• add reverse proxy
• provide example Caddyfile to get them started (this will just be a code block in the docs)
  
• use managed database provider
• change passwords and keys
  
• We'll change the docker setup(s) to use directories mounted as volumes rather than docker-managed named volumes
• This is necessary to ensure safety of users' data
• Easier to understand where data is stored
• We'll leave the 'apt-get' debian installation method for a future release
• We'll keep the "install from scratch" instructions for this release, mark them as "experts only"
• We'll keep the docker compose setup for this release, mark as "deprecated"
• deprecated means we won't support it as an official method in the future
• We will keep it as an example of how one can set up the image as described above in a safer, more maintainable way
• Main difference is in the support a user should expect for the docker compose setup, not the setup itself
• Is there a better way to frame this rather than "deprecated"?
  

These changes are exclusively documentation-related, and will be based off of Mukesh's PR.

Brent

[Kriti Godey]

This plan sounds mostly good to me. I don't think we should deprecate the docker compose setup, given this thread that Mukesh found – many self-hosters seem to prefer it as an installation method. Can we either:

(a) leave it as-is for 0.1.4, or

(b) make the improvements we discussed on our last call – remove inheritance, separate "prod" docker compose from "dev" docker compose, document "prod" more thoroughly.

Also, what is the plan for helping users upgrade to 0.1.4 gracefully? Do we need to write any documentation for that given all the changes in installation?

[Brent Moran]

The inheritance was removed by Pavish in Structures Dockerfile based on operation, and simplifies dev environment .

I'll make an issue for improving the documentation within the docker compose YML itself.

Regarding the deprecation of docker compose, I think it would be good to eventually have that docker compose setup be one of a few options based on a given user's needs, rather than an "Install method" if that makes sense. In the thread you linked, it seems like people see the docker compose file as an example they can use to make their own configuration (hence all the requests for super thorough commenting within the file itself) rather than a plug-and-play installation. I think a lot of the complexity in the file comes from trying to make it both no-config-needed and also configurable. My thinking is that it would eventually be the latter, and users would have other methods for the no-config-needed setup.

For upgrade guidance, there's already some work done in the PR I linked for upgrading to newer installation methods (though if we want to support docker compose for another release or few, some of those aren't needed). There are TODOs in the PR (i.e., in the docs markdown files) where we still need to provide some more information or instructions.

[Kriti Godey]

I think a lot of the complexity in the file comes from trying to make it both no-config-needed and also configurable. My thinking is that it would eventually be the latter, and users would have other methods for the no-config-needed setup.

This makes sense to me. Can we deprecate / remove the “install with guided script” install method and retain the “Install with Docker Compose” method, with the intent of re-doing the “Install with Docker Compose” page so it’s more like https://baserow.io/docs/installation%2Finstall-with-docker-compose?

Everything else in your email sounds good to me.

[Pavish Kumar Ramani Gopal]

> The inheritance was removed by Pavish in Structures Dockerfile based on operation, and simplifies dev environment .

Brent, the PR only removes the inheritance between `dev-service` and the prod `service` containers.

There is one other place where inheritance is still present, between the `test-service` and the prod `service` containers.

--

I think a lot of the complexity in the file comes from trying to make it both no-config-needed and also configurable. My thinking is that it would eventually be the latter, and users would have other methods for the no-config-needed setup.

I'm in full agreement with this statement, however, I think we should still retain the docker-compose instructions on the Installation page, mainly for the sake of higher visibility.

I personally like the nocodb docs which makes it appear dead simple and gets the message across. I think it would be good to have the simplest instructions, and then a separate advanced page/section with all the configurable options, similar to the baserow docs that Kriti linked.