Appflowy cloud deployment test avoidance guide

When I was conducting Appflowy cloud deployment tests, I was struggling with countless pitfalls. Below, I would like to share my experience from several key aspects.

Let me tell you my basic situation first. The deployment of Appflowy cloud is done in a docker environment with docker compose. I have some simple understanding of docker before, but compose has never been used at all. I also have a certain understanding of the Linux environment, but I am not proficient in it. Most of my daily office work is in the Windows environment. The NAS at my home is Synology, which runs based on a Linux environment.

During the deployment process, data review is crucial. Here are some sites and articles I have referenced:

I would like to remind everyone here that you must pay more attention to the official documents. Appflowy +cloud is updated very quickly. If you do not view the official documents in time, once there is an update, you may not know where the error occurs when there is a problem. For example, once I upgraded from 0.916 to 0.917, I found that the background management interface was missing. At that time, I thought there was something wrong with my configuration. I repeatedly tossed and struggled for several days, and finally found that the routing address had changed during the upgrade.

When I was about to start deploying the test, I thought I would run through the process on the computer in the office first, so I downloaded the Windows version of docker and also downloaded the appflowy docker image in this docker (I later learned that it will be automatically downloaded when deploying docker compose, which is really a detour 😂), and also downloaded the source code on github. However, when deploying tests, an exception always appears (now you can't remember the specific error), which will not be able to advance normally. I spent several days on this, but it never solved it. Later I switched the test environment to a linux virtual machine and the error disappeared. Therefore, it is recommended that you deploy Appflowy cloud in a Linux environment. I will eventually deploy it on Synology, because Synology itself is based on Linux, so there is no problem.

Why talk about the choice of database separately? This is because after reading the article of the netizen mentioned above, he mentioned that the database is installed separately, instead of using the database that comes with docker, which makes it easier to backup. I think it makes sense, so I plan to install it separately. The installation process was quite smooth and I didn't encounter any problems. However, when I initialized the database before deployment, I encountered big trouble. I was stuck here for at least 10 days, and the hardships were indescribable. Fortunately, the configuration and connection of the external database were successfully completed. I will explain the specific configuration method in detail in the subsequent configuration article.

For knowledge base applications like Appflowy cloud, the importance of data backup is self-evident. Only by ensuring that the backup process is smoothly completed can I truly deploy it. Therefore, it was another long experience in the process of learning and testing backup. Appflowy cloud's data backup includes database backup and minio file system backup, both of which are indispensable. As mentioned earlier, at first I wanted to install these two applications separately to implement backup, but later I found that I could access and backup operations directly in docker, so in the end I did not install these two software separately. Database backup can be completed through commands, and minio file backup can be directly entered into the minio system and download the compressed package.

As mentioned earlier, Appflowy cloud is an app that has frequent updates, usually there will be updates in one to two weeks. Therefore, it is necessary to understand the upgrade method. The upgrade of the client is relatively simple, just overwrite the installation. But the cloud upgrade on the backend is more troublesome. At first, I thought directly downloading the source code was to upgrade, but I found that this was not the case. In fact, not only do you need to upgrade the docker image, but also update the configuration file. During the process of learning and upgrading, I learned the relevant commands of git and found that it would be more convenient to upgrade with git. I will share in detail the specific operation method in the future.

 

Let’s share this here today. I will find time to introduce the deployment method in detail later. I hope it will be helpful to everyone. 💖