Полезные статьи. Перенос сайта c виртуального хостинга на VPS c помощью Vesta. LTD Beget.

Почтовый сервер

Хотя некоторые приложения могут напрямую подключаться к внешнему SMTP (что очень даже хорошо: в случае взлома провайдер не забанит аккаунт из-за рассылки спама), но в большинстве приложений для отправки почты используют функцию mail(), а поэтому нам потребуется локальный SMTP-сервер.

Здесь опять два варианта: настроить полноценный сервер или установить прокси, который будет подменять SMTP, переправляя запросы на внешний сервер (потребуется почтовый ящик). В качестве последнего отлично подходит ssmtp, который есть в репозитории. Хотя установить «большой» сервер в минимальной конфигурации — дело пяти минут.

# apt install postfix

В процессе выбираем «Интернет-сайт» и указываем домен.

# nano /etc/postfix/main.cf
myhostname = example.org
mydestination = $myhostname, localhost.localdomain, localhost
# Чтобы подключались только с локальных адресов
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

Перезапускаем:

# service postfix restart

И почта должна уже работать. Единственный момент — если почтовый ящик домена привязан к Gmail, то, когда в него идет письмо с этого же домена, технология DMARC Gmail может его отбросить как спам. Хотя если отправитель будет другой, то все будет работать.

mydestination = $mydomain, localhost.$mydomain, localhost

Первоначальные настройки сервера

OC в VDS устанавливается автоматически. Достаточно выбрать версию и вариант с веб-панелью или без и чуть подождать, пока не придет письмо с данными для входа. На хостингах предлагаются и разные веб-панели. Когда этот материал создавался, Vesta не поддерживала Ubuntu 16.

04 и необходимости в ней не было, поэтому выбрали чистую систему. Все дальнейшие действия ведутся от имени root. Первым делом проверяем локаль, часовой пояс и время. Вообще, веб-приложения обычно не обращают внимания на некоторые системные настройки, но иногда попадается именно тот случай, поэтому лучше сразу сделать все правильно.

# locale

Если в ответ получаем отличное от ru_RU.UTF — перенастраиваем.

# locale-gen ru_RU ru_RU.UTF-8 ru_RU ru_RU.UTF-8
# localedef -c -i ru_RU -f UTF-8 ru_RU.UTF-8
# dpkg-reconfigure locales
# update-locale LANG=ru_RU.UTF-8

Проверяем время:

# date

Если часовой пояс не соответствует — переконфигурируем.

# dpkg-reconfigure tzdata

Обновляем сервер:

# apt update && apt upgrade

Теперь можем ставить сервисы.

Настройка домена

Домен может быть зарегистрирован у хостинг-провайдера, где расположен сайт или у отдельного регистратора. Я всегда советую регистрировать домен отдельно от хостинга. Так как в таком случае при переезде сайта вам не придётся переносить домен к новому регистратору. Достаточно сменит DNS сервера.

Узнать новые DNS можно в панели хостинга. Обычно они прописаны в разделе «Домены» или где-то на видном месте.

Учтите, что перенастройка DNS может затянуться до 72 часов. Так что после переноса сайта на новый хостинг не спешите удалять его со старого. Таким образом, перенос пройдёт без перебоев работе ресурса.

Настраиваются же адреса в разделе DNS для конкретного домена. И выглядит это так:

Независимо где зарегистрирован ваш домен, вы должны указать в его настройках NS-сервера нового хостинга.

Настройка прав доступа

Для дальнейшей настройки потребуется подключиться к серверу по SSH — рекомендуем использовать для этого удобный вам SSH-клиент (например, Putty в Windows) или стандартный терминал в Linux или MacOS.

Если вы добавили SSH-ключ для авторизации без ввода пароля, достаточно набрать в терминале:

где xxx.xxx.xxx.xxx — IP-адрес вашего сервера. Иначе потребуется ввести пароль, указанный при создании сервера (если вы забыли пароль, в любой момент его можно сбросить в настройках сервера).

Если нет возможности воспользоваться SSH-клиентом, вы можете открыть терминал в нашей панели управления — необходимо выполнить вход на сервер под пользователем root с паролем, установленным при создании сервера.

Перенос joomla на хостинг

public $host = 'localhost';

public $user = 'host6578395';

public $db = 'host6578395';

public $password = 'qwerty';

/home/логин/домен.ru/htdocs/www

public $log_path = '/home/host6578395/домен.ru/htdocs/www/logs';
public $tmp_path = '/home/host6578395/домен.ru/htdocs/www/tmp';

Перенос сайта на joomla для нетерпеливых —

Переносим базу данных

Это самый важный этап. Если при копировании базы данных возникнут ошибки, сайт не будет работать корректно, а часть информации и вовсе может исчезнуть. Могут возникнуть проблемы с кодировкой информации, страницы будут неправильно отображаться.

• Сначала производим копирование на локальный диск.

Заходим на функционирующий хостинг, выбираем базу данных и записываем ее кодировку. После этого экспортируем базу в архив, теперь все данные скопированы на компьютер.

Заходим на хостинг нового провайдера и создаем новую базу данных. Если в созданной базе имеются таблицы, необходимо удалить их. Переходим раздел «Импорт» и копируем данные, для этого выбираем старую кодировку.

База данных перенесена. Если вы обнаружили ошибки или процесс прервался, повторите все заново. Обратите внимание, что перед каждым переносом нужно сохранять на локальный диск резервную копию, в противном случае вы рискуете потерять ценную информацию без возможности восстановления.

Подключаемся к bitbucket

Вся изюминка переноса состояла в использовании при разработке веб-сайта Git. Выглядело интересно, осталось только это все реализовать. Здесь можно пойти несколькими путями. Самый, наверное, простой — инициализировать локальный репозиторий и позволить разработчику при коммите выкладывать файлы прямо на сервер.

Минус здесь — мы фактически даем ему доступ на сервер. Поэтому лучше перестраховаться, и самым правильным вариантом будет использовать посредника с возможностью автоматического pull файлов после коммита. Так мы получаем еще один источник бэкапа. В качестве промежуточного сервиса был выбран сервис «ведро битов» Bitbucket, предлагающий всякие вкусности вроде бесплатных «private»-репозиториев и удобного интерфейса. Хотя, в принципе, это может быть любой другой подобный сервис — GitHub или Google Cloud Source Repositories.

Механизм взаимодействия будет простым. Создаем репозиторий (можно в отдельной теме), инициализируем Git прямо в корне сайта (как вариант, можно переносить с другого каталога, но это не так интересно), добавляем удаленный репозиторий Bitbucket и подключаем сервер к аккаунту Bitbucket.

Постановка задачи

Ситуация самая жизненная. Интернет-магазин, размещенный на шаред-хостинге, после запуска начал получать клиентов, но появились пожелания к функциональности, и разработчики активно занялись доработкой сайта. Выяснилось, что, когда в этом участвует несколько человек, постоянно копировать файлы через FTP для теста, да и еще на рабочий сайт, очень проблемно.

Терялся контроль, кто когда что сделал, нужно было беспокоиться о сохранении оригинальных файлов, чтобы было легко откатиться. Владельцу приходилось или согласовывать правки, или копировать все самому. Разработчик не мог сразу посмотреть результат и ждал.

Процесс сильно тормозился. В итоге пришли к тому, что нужно использовать возможности Git и создать новый сайт-зеркало, где можно было бы все обкатывать. При такой схеме разработчик мог сразу тестировать код, а в случае одобрения код переносили в master и выкладывали уже на рабочий сайт. Также можно легко отслеживать коммиты.

Вторая проблема: хостинг постоянно падал. Причину в итоге нашли: Entry processes limit — параметр, который определяет количество CGI/PHP-процессов, входящих внутрь виртуального контейнера, и о котором не сильно любят говорить маркетологи хостера. На графиках его тоже не видно, только маленькая графа в таблице.

Ставим веб-сервер

Несмотря на их разнообразие, выбор установки обычно сводится к трем вариантам: Apache, nginx или nginx как реверс Apache. Apache очень гибок в настройках и использует модули для обработки динамических запросов, поэтому хорошо справляется с динамикой.

Nginx хорош в отдаче статики и потребляет меньше ресурсов, но для обработки динамики использует сторонний модуль, что снижает скорость и чуть усложняет настройки. В зависимости от конкретного приложения каждый из них может иметь свои плюсы и минусы и показывать разную скорость.

Поэтому окончательный выбор веб-сервера всегда приходится подтверждать практикой, подбирая оптимальный вариант. Проблема nginx — то, что в некоторых специфических движках следует вручную возиться с редиректами, когда на Apache все будет работать буквально из коробки, достаточно просто включить mod_rewrite.

Нагрузочное тестирование можно произвести при помощи ab (Apache Benchmark, входит в apache2-utils) или siege. Причем лучше проверить с localhost и удаленного узла, чтобы видеть, как работает сеть.

Шаг 4: переносим учетные записи e-mail

Этот шаг важен тем, кто активно использует в работе электронную почту. Варианты «почтовой» миграции зависят от изначальных сценариев использования данного канала связи:

1. Адрес почты находится на регистраторе доменного имени. Самый удобный вариант. Для переноса учётных записей e-mail нужно просто зайти в аккаунт регистратора и привязать почтовый сервер на IP-адрес выбранного хостинга.
2. Электронная почта привязана к сервису-посреднику (например, Microsoft 365, Google G Suite, МойОфис). В этом случае нужно проверить, обновляются ли в DNS записи MX, необходимые поставщику e-mail услуг.
3. Адрес электронной почты размещен на сервере старого хостинг-провайдера. Тогда придется потратить время, чтобы заново создать учетные записи на новом хостинге. Для этого нужно воспользоваться функцией импорта e-mail в разделе «Электронная почта».

Этап 1. планирование и подготовка

Настоятельно не рекомендуем пропускать этот этап, даже если на первый взгляд все просто. Здесь уместно вспомнить поговорку «гладко было на бумаге, да забыли про овраги», которая как нельзя лучше подходит для описания многих таких «лихих» переносов.

Прежде всего выясните все «явки и пароли», а таких может быть много: учетные данные в админку сайта, в панель управления хостингом, в личный кабинет регистратора доменных имен, параметры доступа к FTP, MySQL и т.д. Если на сайте установлен разного рода партнерский или рекламный код, то уточните доступ в соответствующие личные кабинеты. Если используется обмен с товароучетной системой, то также уточните параметры доступа с обоих сторон.

Затем произведите полную инвентаризацию старого хостинга, какие настройки и модули веб-сервера установлены и применяются, где расположены файлы, и кто является их владельцем, какие имеются пользователи и какие у них права доступа. Чем больше вы проверите и запишете, тем проще будет работать в дальнейшем.

Не забудьте уточнить версии используемых CMS и модулей к ним, после чего обязательно проверьте их совместимость с планируемым к использованию на новом сервере ПО, в частности следует обратить внимание на версию PHP. При необходимости запланируйте их обновление, которое лучше всего попробовать выполнить на стенде еще до начала всех мероприятий.

После того, как все учтено и записано переходите к планированию. Старая шутка говорит, что полученное при предварительном расчете время нужно смело умножать на два и переходить к значениям более высокого порядка. Но в любой шутке есть доля истины. Наш опыт показывает, что минимальным запасом времени для выполнения всех операций следует считать неделю, а лучше всего две.

Этап 3. подготавливаем домен к переносу

Наиболее длительным и неконтролируемым этапом при переносе является изменение настроек DNS, которые должны перенаправить посетителей на новый сервер. Обычно считается что DNS-сервера обновляются от нескольких часов до суток и повлиять на этот процесс нельзя.

Но ранее мы не зря говорили, что очень важен собственноручный контроль над DNS-зоной. Найдем в ней SOA-запись, это основная запись зоны и нас в ней должен интересовать параметр Minimum TTL — это минимальное время жизни ресурсных записей зоны, которое указывает другим серверам сколько времени они могут хранить в кеше полученную информацию.

Но это скорее исключение, чем правило и уменьшение TTL гарантированно позволяет быстро переключить основную аудиторию на новый сервер в течении небольшого промежутка времени.

Этап 5. заключительная синхронизация и перенаправление домена

Допустим вы все проверили и убедились, что на новом месте все хорошо. Теперь следует выполнить заключительные штрихи и окончательно перенести ресурс на новый сервер. Для этого переведите старый сайт в режим только чтение. Не следует включать режим обслуживания или как-либо еще делать его недоступным для посетителей, просто отключите возможность пользователям изменять его содержимое или размещать заказы. Также обязательно разместите на видном месте сообщение о технических работах.

Теперь следует синхронизировать последние изменения между старым и новым сервером, если доступно подключение через SSH — то удобно использовать rsync, в противном случае просто заново залейте содержимое на новый сервер, указав перезаписывать только явно измененные файлы.

После чего изменяем DNS-записи таким образом, чтобы они указывали на новый сайт. Если вы предварительно уменьшили TTL, то первые посетители начнут приходить уже через 10-15 минут. Кстати не забудьте после изменения DNS-записей снова увеличить TTL.

Если вы все сделали правильно, то для большинства посетителей переезд пройдет незамеченным, особенно если вы подгадаете заключительный этап на время с наименьшей посещаемостью (ночное время, выходной или праздничный день). Самые настойчивые в течении короткого времени будут видеть сообщение, что идут технические работы и некоторые функции сайта ограничены.

Полностью переход обычно завершается в течении суток, но не следует забывать о тех DNS-серверах, которые игнорируют TTL, поэтому мы рекомендуем держать старый сервер в работе еще некоторое время, как минимум неделю. В своей практике мы оставляем его в работе до конца оплаченного периода.

Этап № 3 — выбор хостинга

От выбора качественного хостинга зависит множество моментов связанных с успешным продвижением веб-проекта. Не так давно я опубликовал статью «Как выбрать хостинг», с которой всем рекомендую ознакомиться. В зависимости от хостинг-провайдера на главной странице каждого сервиса предлагаются различные услуги и перечислены все его преимущества.

Практически у каждой площадки существует тестовый период, а он нам необходим, поскольку, с чем черт не шутит. Особо не вдаваясь в подробности объясню — тестовый период нужен для того, чтобы потенциальный клиент (то есть мы с вами) мог без предоплаты установить свой веб-проект и проверить стабильность работы того или иного провайдера.

Не смотря на огромнейшую конкуренцию в данной нише, я все же определился и решил припарковаться на отечественном портале parkovka.ua. Уж больно здесь цены заманчивые, да и отзывы об этом сервисе хороши. Подробнее об этом провайдере можно узнать с вот этой статьи.

Этап № 4 — выбор доменного имени

На данном этапе важно выбрать имя которое бы отражало сущность вашего проекта. Сначала я зарегистрировался на вышеуказанном хостинге, после чего здесь же заказал домен.

Для начала на главной странице сайта необходимо войти во вкладку «Домены», затем  прописать имя в соответственном поле и нажать кнопку «Проверка».

Напротив свободного домена будет отображаться зеленая кнопка «В корзину», нажимаем. В итоге система сообщит о том, что ваш домен добавлен в корзину. Кликаем «Оформить заказ».

Заметьте при регистрации доменного имени важно вносить подлинные данные. То есть, в процессе заполнения специально отведенной формы, необходимо прописать ваше имя, фамилию, отчество, адрес, существующий E-mail и т. д. После внесения всех данных нажимаем кнопку «Оформить». С примером регистрационной формы можно ознакомиться на скриншоте.

Действительные данные нужны как минимум для того, чтобы в будущем какой-то умник не заявил, что зарегистрированный ранее вами домен принадлежит ему. Также это актуально в тех случаях, когда сайт пользуется огромной популярностью и у вас есть покупатель, готовый выложить за него солидную сумму.

Так как я решил приобрести домен и хостинг услуги у одного провайдера, привязка DNS с моей стороны не требовалась. На Parkovka.ua это осуществляется в автоматическом режиме. Тестовый период на данном ресурсе запускается автоматом, стоит лишь только заполнить регистрационные поля и активировать свой аккаунт.

Вместо заключения. некоторые финансовые вопросы.

Хостинг — услуга платная и, чаще всего, долгосрочная. Поэтому не следует пренебрегать финансовыми вопросами, особенно если вы не хотите небольших, но иногда достаточно неприятных проблем. Отечественные хостеры как правило практикуют предоплату на срок от месяца, наиболее выгодно оплачивать годовое размещение. Перед окончанием оплаченного периода вам нужно внести новую оплату или услуги вам будут приостановлены.

Если вы этого не сделали, то никаких финансовых санкций к вам применено не будет, а через некоторое время (обычно месяц) все ваши данные будут удалены, до истечения этого периода у вас будет возможность их забрать. Также если вы приобретали у данного поставщика иные услуги, то на них это никак не отразится, будет блокирована, а затем удалена только неоплаченная услуга. Это достаточно просто и понятно и к этому все привыкли.

У зарубежных хостеров практикуется принципиально иной подход. Чаще всего оплата списывается ежемесячно, в автоматическом режиме с кредитной карты или через PayPal, если это невозможно, то ежемесячно выставляются счета, которые вы должны самостоятельно оплатить в течении некоторого времени, обычно 14 дней. При этом контракт может быть заключен на больший срок, чаще всего на год.

Сроки расторжения контракта указываются отдельно, для обычно не позже чем за 6 недель до его окончания. Т.е. если вы хотите закончить сотрудничество в конце текущего месяца вы должны были уведомить об этом хостера еще в середине предыдущего. Кроме того, годовой контракт не всегда можно расторгнуть досрочно без уплаты неустойки.

Что будет если вы не уведомите провайдера о расторжении контракта? Вам будет выставлен счет за следующий период, либо будет произведено автоматическое списание средств. И даже если вы сразу после этого заявите о расторжении, то вам скорее всего придется оплатить этот месяц и следующий.

Если вы не оплатите счет, то предоставление услуг будет вам приостановлено, но это не освобождает вас от оплаты, так как контракт продолжает действовать. При этом приостановлены могут быть все услуги на вашем аккаунте, что особенно актуально в тех случаях, когда вы приобретаете новую услугу с отказом от старой в пределах одного хостера. Это может оказаться неприятным сюрпризом и привести к дополнительным финансовым тратам.

В том случае, если вы покидаете хостера и отключили автоплатеж в его пользу, то взыскать с вас он вряд ли чего сможет, но кто знает, как повернется ситуация и не придется ли вам к нему вернуться. Поэтому лучше не портить свою финансовую репутацию и содержать свои дела в порядке.

Описанная схема наиболее характерна для европейских хостеров, американские компании могут предлагать иные условия, но опять-таки все упирается в понятие контракта и его автоматическое продление. Так американский хостер может брать оплату сразу за год и если вы явно не откажетесь от его услуг, то контракт будет автоматически продлен, и вы окажетесь перед необходимостью оплатить еще год размещения, либо расторгать контракт через поддержку с уплатой неустойки, остальные ваши услуги на это время могут оказаться заблокированы.

Также обратите внимание, что большинство американских хостеров не предоставляют безлимитный трафик, выделяя в рамках тарифа определенный ежемесячный объем, после превышения которого вам выставят дополнительный счет, либо потребуют приобрести дополнительный пакет трафика, услуга при этом также может быть заблокирована.

В любом случае перед приобретением услуг хостинга, как в России, так и за рубежом внимательно изучите финансовую сторону дела, особенно процесс оплаты и расторжения договора, в т.ч. досрочного, если вам что-то непонятно, то не стесняйтесь уточнить этот момент в поддержке.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.