How to deploy changes to a production website while not taking the website down for a fraction of a second?
I use Git to manage the development cycle of my web application, and for changes where a git pull is enough and no changes needed, I just naturally keep the site up and git pull the changes.
But I'm thinking, say I have 100 files changed, and say there was some unexpected load on the disk, what happens if someone does a request during the moment that git was committing changes on disk? Wouldn't that make my application possibly vulnerable to possible data corruption or malformed responses?
I mean this is very, very unlikely for a low traffic website, but if you get some really high traffic, and happens to be a spike server load, there's some risk.
I actually thought of a solution but it is probably not the best if I roll my own implementation and I'm rather not sure if its practical. I remember reading an article on how we do not see artifacts on our screens, basically by writing new data to an entirely different block on the GPU memory, and then just switching the up to date screen data (whatever that is called) pointer to the new block, and possibly discarding or reusing the old block in the end. This way if a GPU lags no half-written data will be shown
Would this be practical if one could implement such a similar thing?
Вам понадобится балансировщик нагрузки. Он может обеспечивать постепенные обновления, высокую доступность и горизонтальное масштабирование.
Большие, нетривиальные, но почему-то постоянно обновляемые веб-сайты постоянно меняются незначительно. Возможно, они выпускают ежедневное обновление или какая-то функция не работает, но все еще работает. Они решили, что не стоит отказываться от немного другого пользовательского опыта. Вам нужно будет принять собственное решение о том, включает ли ваше решение запланированное время простоя.
На отдельном веб-сервере определенные методы развертывания обеспечивают более резкий переход. Предварительное развертывание кода и последующее его перемещение на место - более чистый вариант, чем обновление рабочей копии в реальном времени. Хотя это не учитывает базы данных, обновления веб-сервера и другие сложности. Вы по-прежнему хотите, чтобы балансировщик нагрузки давал вам возможность выбора.
Один из канонических способов сделать это, независимо от того, используете ли вы git или нет (но с его помощью вы можете реализовать эту схему с некоторыми из его хуков) , должен иметь каталог на веб-сайте, куда вы устанавливаете каждую новую «версию» в ее собственном конкретном каталоге, например, с отметкой даты / времени в ее имени. Настоящий текущий контент, используемый веб-сервером в данный момент, находится в другом пути, который является символической ссылкой на один каталог «версии».
После завершения передачи и после того, как вы проверили, что все прошло хорошо (отсутствие недостающих файлов, достоверное содержимое, правильные права Unix, отсутствие болтающихся символических ссылок и т. д.), вам просто нужно изменить символическую ссылку с пути "production" на путь новой "версии".
Изменение символической ссылки почти атомарно, поэтому это не приведет к нарушению .
Это также позволяет легко вернуться: просто снова измените символическую ссылку.