Asbo

Как сделать что то подобное?

Виджет PayPal-a (первый скрин) вставляете себе на сайт и всё.

Мне кажется девопсом становятся только на практике

Как выше уже сказали профессии такой нет, но есть инженеры, которые используют DevOps практики.
Я в эту профессию попал из системного администрирования, имея довольно неплохой бэкграунд и последнее время склоняюсь к тому, что это не та профессия, которую нужно начинать с нуля. Сейчас пытаюсь разработать внутренние курсы для для своего работодателя, чтобы привлечь в профессию ops инженеров или разработчиков. Сначала думал что можно дать материал джунам, но в итоге пришёл к выводу, что для начала нужно поработать в разработке\администрировании до уровня мидла, чтобы иметь представление о том как вообще работают системы, как они разрабатываются и эксплуатируются, параллельно можно изучать DevOps инструменты.
По курсам посоветую только базовые курсы, любые какие вам по душе по темам: Linux, Python, Docker, Kubernetes, Jenkins, Git.

что должен знать идеальный джуниор (мое личное мнение):

- Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
- GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
- Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
- PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
- Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
- Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
- Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
- Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
- Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
- Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
- Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
- Уметь дебажить. xdebug, blackfire и тд.

В целом где-то за годик весь этот список можно влегкую покрыть с нуля.

p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

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

Следует начать с проектирования API. Возмите https://swagger.io/ и набросайте все, что нужно.
Swagger вам позволяет объединить роутинг, документацию и примеры вызовов в единое целое.
Кроме этого он позволяет сгенерировать заглушки для разных языков программирования и фреймворков.
В принципе вы можете найти значительное количество интеграций для разных фреймоворков.

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

В REST есть 6 принципов, прекрасно изложенных в Wiki. В REST нет ничего сложного и особенного. Это просто надстройка над стандартным протоколом HTTP. Именно поэтому нет никаких особенных уроков. Изучите работу HTTP и вы поймете как работает веб в целом и REST в частности.

По поводу отдельного сервера для API. Есть множество разных подходов. В последнее время все более актуальными становятся Serverless-приложения. Serverless архитектура идеально вписывается в REST. Но думаю для вас это пока рановато и сложновато. Слишком много для начала.

Логичнее всего держать проект в моно-репозитарии, если он не будет большим. Если вы точно не знаете насколько большим он будет, то можно разбить проект на компоненты и использовать Composer для управления зависимостями (советую полность прочитать эту страницу от корки до корки).

По поводу best practices есть очень хороший ресурс https://12factor.net/ru/
Он в целом применяется для всех приложений.

Запомните: первый блин всегда комом. Прочитайте все ресурсы, которые я привел для вас. В них много ссылок на другие, походите по ним, присмотритесь. Напишите первую версию API так, как вам кажется удобно. Постарайтесь применить практики из статей.
Вам нужен опыт и вы его не наберетесь, пока не сделаете что-то сами. Вы можете потратить год на чтение, но останетесь на том же месте, с которого начали. А другой человек напишет на коленке API за неделю, а потом перепишет его 20 раз за год и он вам расскажет в 10 раз больше, чем то, что вы изучили за год.
Дерзайте!

Судя по "Хочу поднять VPN-сервер на нем, чтобы отдавать один сайт."
"То есть не было доступа к 80 порту сервера до установления соединения по VPN. "
"Какой сервер тут лучше использовать и как ограничить доступ к нему из интернета?"

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

ВСЕ, не нужны никакие дополнительные сервера.

Начинал с notepad++ затем сублайм, затем глючный атом, потом был vscode ну и в конце phpstorm. Да и остальные всякие разные редакторы пробовал. NetBeans, PHPeD(неплохая штука кстати), Eclipse. У шторма есть несколько плюсов, которые возвышают его над конкуретнами. Во первых из коробки он может намного больше чем надо. Удобная работа с гитом? Есть. (особенно клевый интерфейс для мерджей). Поддержка тестов есть, эмет есть...да куча всего есть. При этом достаточно быстро работает. Это одна из немногих ide, в которой ты работаешь, а не сражаешься. Я так привык к шторму, что любые другие редакторы не идут. Заходить в vscode, затем подтягивать кучу плагинов, настраивать все это, словить пару багов...не. Не хочу. Надоело.

Программирую на Рельсах. Для деплоя использую Capistrano. Очень удобно.

Рекомендую Capistrano (http://habrahabr.ru/tag/capistrano/):
— мы используем вместе с модулем multistage, он позволяет разворачивать код на несколько stage-серверов (по команде «cap demo deploy» выкладывается ветка testing на демо-сервер, «cap production deploy» — ветка master на боевой)
— позволяет делать cached-copy: при первом развёртывании создаётся папка с клоном репозитория, при последующих — в ней делается git pull. Далее эта папка тупо копируется в целевую вместе с .git (у нас www-root находится не в корне проекта, а в одной из вложенных папок — так что паранойя нас сильно не мучает)
— deploy:rollback — откат к предыдущему деплою
— возможно задавать всякие разные задачи: before update, after update, restart, web:disable (блокировка сервера на период обновления)
— так же нашли и допилили модуль для создания тегов при каждом деплое — теперь прямо в дереве коммитов можно легко определить кто, что, куда и когда деплоил. Различия между версиями? Пожалуйста. Дату релиза? Пожалуйста. Конфетка получилась :)
— деплой на 10 серверов разом и выполнение всяких разных команд локально\удалённо — само собой разумеющееся