Wipe out historical Docker info from Configuration guide #51024
+65
−226
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
This change wipes out a bunch of historical Docker-based configuration information. It is not meant to be a general upgrade of this section and I have not invested a lot of time into verifying the existing information other than correcting a few links and typos. I'll assume the configurations remain broadly correct.
How
Remove all Docker and docker-compose configuration information, leaving only Kubernetes info.
It's worth noting that this change totally deletes the database configuration page. I am open to the opinion that it should be retained and just the Docker information removed. However, my thought process is this page has been superseded by the current database configuration page in the deployment guide, which I'll be expanding on soon anyway, and the new deployment guides will basically render this entire section obsolete. See Detailed deployment docs to learn more.
Review guide
Check the "Configuring Airbyte" page and its (now 2) child pages. https://airbyte-docs-git-11322-remove-docker-from-config-airbyte-growth.vercel.app/operator-guides/configuring-airbyte
User Impact
The persistence of docker-compose context is one of the types of complaints we've received about our deployment docs. This should help by avoiding the perception that docker-compose is even a consideration now.
Can this PR be safely reverted and rolled back?