Сервер Caddy in Go Нажмите кнопку «Интегрировать»

Caddy – это веб-сервер, обладающий рядом функций, обеспечивающих простоту и безопасность, что важно при хостинге сайтов. К примеру, Caddy умеет в автоматическом режиме получать TLS-сертификаты от Let’s Encrypt и управлять ими для обеспечения функционирования протокола HTTPS. Caddy также включает в себя поддержку HTTP/2. В данном руководстве мы изучим, как организовать хостинг своего сайта защищенного с помощью HTTPS при помощи Caddy в Ubuntu 20.04.

Установка Go

На первом шаге, нам необходимо будет установить и настроить локальную среду программирования языка Go.

Для начала обновите список пакетов:

$ sudo apt update

После чего, перейдите в домашний каталог и запустите загрузку последней версии Go, доступной на официальной странице:

$ cd ~
$ curl -O https://dl.google.com/go/go1.16.6.linux-amd64.tar.gz

Для проверки контрольной суммы скачанного дистрибутива, используйте команду sha256sum:

$ sha256sum go1.16.6.linux-amd64.tar.gz

Контрольная сумма, выведенная командой sha256sum, должна совпадать с контрольной суммой скачанного файла, указанной на странице загрузки:

Далее, загруженный архив необходимо разархивировать и скопировать его содержимое в директорию /usr/local:

$ sudo tar -xvf go1.16.6.linux-amd64.tar.gz -C /usr/local/

Таким образом, вы создадите каталог go в директории /usr/local, для которого необходимо назначить владельцем пользователя и группу root. Это обезопасит данные файлы и гарантирует, что только пользователь root сможет запускать на выполнение бинарные файлы Go:

$ sudo chown -R root:root /usr/local/go

Создание рабочего пространства Go

По умолчанию, директория рабочего пространства Go это – домашний каталог вашего пользователя, содержащий подкаталог go. Создание структуры каталогов для рабочего пространства Go производится при помощи следующей команды:

Далее, необходимо установить значение глобальной переменной $GOPATH в файле ~/.profile. Для чего откройте этот файл при помощи, например, nano:

$ sudo nano ~/.profile

В конец файла добавьте следующие строки:

export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin:/usr/local/go/bin

Следующей командой запустите загрузку глобальных переменных:

$ . ~/.profile

Теперь, вы можете проверить версию установленного пакета Go:

$ go version

На этом настройка Go может быть завершена.

Построение Caddy

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

Перейдите на страницу релизов и скопируйте ссылку на последний релиз для платформы linux_amd64. Перед началом загрузки перейдите в каталог /tmp, для чего наберите в командной строке:

$ cd /tmp

Теперь, запустите загрузку архива дистрибутива:

$ wget https://github.com/caddyserver/xcaddy/releases/download/v0.1.9/xcaddy_0.1.9_linux_arm64.tar.gz

После окончания загрузки, скачанный архив необходимо разархивировать:

$ tar xvf xcaddy_0.1.9_linux_amd64.tar.gz xcaddy

Далее, переместите xcaddy в каталог /usr/bin для того, чтобы сделать этот файл доступным для всей системы:

$ sudo mv xcaddy /usr/bin/

Теперь, когда xcaddy установлен, нужно собрать Caddy. Для этого создайте отдельный каталог в домашней директории вашего пользователя и перейдите в него:

$ cd ~
$ mkdir caddy
$ cd caddy

И наконец, чтобы собрать последнюю версию Caddy, не используя при этом какие-либо сторонние плагины, запустите следующую команду:

$ xcaddy build

Построение структуры Caddy займёт какое-то время, и как только сборка закончится, вам будет доступен исполняемый файл caddy. Он находится в текущем каталоге, откуда его следует переместить в директорию /usr/bin:

$ sudo mv caddy /usr/bin

Теперь попробуйте проверить версию установленного пакета:

$ caddy version

Вывод команды должен содержать номер версии Caddy:

Установка Caddy

В данном разделе мы настроим службу Caddy таким образом, чтобы она могла автоматически стартовать при запуске системы.

Во-первых, для этого Caddy нужен свой собственный пользователь и группа. Следующей командой создайте такую группу. Она будет называться caddy:

$ sudo groupadd —system caddy

Затем, создайте пользователя caddy, который будет входить в группу caddy:

У нового пользователя будет свой собственный домашний каталог: /var/lib/caddy. Правда, подключиться к оболочке под именем caddy не получится, так как для неё установлено значение nologin.

Далее, чтобы предотвратить возможность модификации исполняемого файла Caddy другими учётными записями, измените владельца для файла /usr/bin/caddy:

$ sudo chown root:root /usr/bin/caddy

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

$ sudo chmod 755 /usr/bin/caddy

На этом настройка исполнительного файла Caddy завершена и можно приступить к написанию конфигурации Caddy.

Создание конфигурации Caddy

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

$ sudo mkdir /etc/caddy
$ sudo chown -R root:caddy /etc/caddy

Данная настройка для пользователя root и группы caddy будет гарантировать нам то, что Caddy получит доступ к этому каталогу на чтение и запись (через группу caddy), а также то, что права на чтение и модификацию содержимого данной директории будет иметь только учетная запись суперпользователя.

Следующим шагом, нужно будет включить автоматическое предоставление сертификатов TLS-сертификатов от сервиса Let’s Encrypt. Создайте каталог, в котором будут храниться сертификаты, полученные для Caddy, и предоставьте этому каталогу такие же права, что и для директории /etc/caddy:

$ sudo mkdir /etc/ssl/caddy
$ sudo chown -R root:caddy /etc/ssl/caddy

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

$ sudo chmod 0770 /etc/ssl/caddy

Следующим шагом необходимо создать каталог для файлов, с которыми будет работать Caddy, и установить для него владельца и группу caddy:

$ sudo mkdir /var/www
$ sudo chown caddy:caddy /var/www

Конфигурация Caddy хранится в файле Caddyfile, находящемся в каталоге /etc/caddy. Такой файл необходимо создать:

$ sudo touch /etc/caddy/Caddyfile

Чтобы установить службу Caddy, с GitHub-репозитория Caddy загрузите файл сервиса Caddy. Его следует поместить в /etc/systemd/system:

Измените права на этот файл так, чтобы только пользователь root мог вносить в него изменения:

$ sudo chmod 644 /etc/systemd/system/caddy.service

Затем, перезапустите подсистему управления службами, чтобы проверить сервис Caddy:

$ sudo systemctl daemon-reload

После чего, проверьте статус службы Caddy:

$ sudo systemctl status caddy

Вывод команды должен выглядеть примерно так:

И наконец, чтобы Caddy мог обслуживать как HTTP, так и HTTPS трафик на вашем сервере, вам нужно будет выдать соответствующие разрешения в брандмауэре UFW:

$ sudo ufw allow proto tcp from any to any port 80,443

Теперь, если вы запустите проверку статуса вашего брандмауэра:

$ sudo ufw status

то должны увидеть выданные разрешения в следующем виде:

Настройка Caddy

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

Начнём с того, что создадим в директории /var/www страницу нашего базового сайта index.html:

$ sudo nano /var/www/index.html

Теперь, вставьте в него какую-нибудь html-разметку, например:

Закройте файл, сохранив изменения. После чего, откройте файл конфигурации Caddyfile, который вы создали чуть ранее:

$ sudo nano /etc/caddy/Caddyfile

В этот файл добавьте следующие строки:

Это – основная настройка Caddy. Она говорит, что весь HTTP-трафик на вашем сервере должен обслуживаться при помощи файлов (file_server), находящихся в директории /var/www, которая является для вашего сайта корневой, а также, должен сжиматься при помощи gzip в целях сокращения времени загрузки обслуживаемых страниц на клиентской стороне.

Этот файл также закройте, сохранив изменения.

И теперь, чтобы проверить, действительно ли всё это будет работать, запустите службу Caddy:

$ sudo systemctl start caddy

После чего, проверьте статус запущенной службы:

При этом, увидеть вы должны примерно следующее:

Это означает, что сейчас Caddy работает и настроен для обслуживания статических файлов на нашем сервере.

Настройка TLS сертификатов Let’s Encrypt

Мы уже упоминали, что такой веб-сервер как Caddy умеет работать с TLS-сертификатами в автоматическом режиме. Caddy сам их запрашивает и обновляет, и, соответственно, имеет возможность обслуживать размещённые на нём сайты при помощи защищённых соединений.

Ранее, при установке Caddy, мы уже внесли изменение в настройки брандмауэра UFW, которое позволяет веб-серверу обслуживать HTTPS-трафик. Для того, чтобы это действительно заработало, осталось сделать небольшие поправки в конфигурации самого Caddy.

Настройка будет заключаться во внесении изменений в конфигурационный файл Caddy. Поэтому, перейдите в каталог /etc/caddy и откройте для редактирования файл Caddyfile:

$ cd /etc/caddy
$ sudo nano Caddyfile

В тексте файла следует заменить строку http:// на имя вашего домена. Также, нужно будет добавить строку tls с указанием актуального E-mail. В нашем случае текст файла Caddyfile выглядит как:

После сохранения внесённых в файл изменений перезапустите Caddy:

$ sudo systemctl restart caddy

И, чтобы убедиться, что всё работает, наберите в браузере адрес своего сайта с префиксом https://

Caddy web server

Caddy is a web server created with ease of use in mind. It’s perfect to use in development by is simplicity and strong enougth to use in production .

It features a simple configuration file, HTTP/2 and automatic TLS encryption. HTTP/2 is the new version of the HTTP protocol that makes websites faster by using single connection for transferring multiple files and header compression among other features. TLS is used to serve websites encrypted over a secure connection and, while it has been widely adopted on the Internet, it’s often a hassle to get and install certificates manually.

Caddy use Let’s Encrypt, a certificate authority which provides free TLS/SSL certificates and automatically obtains and renews the certificates when needed.

In this tutorial, you will install and configure Caddy. You will have a simple working website served using HTTP/2 and a secure TLS connection.

Script install

For automatic install you can just execute :

It will detect automatically your platform and download the appropriate binaries to install.

You can also specify plugin

The command output will look like this:

When the script finished installing you can verify the caddy installation with this command :

The command output will give you /usr/local/bin/caddy .

Install without the script

If you need a more custom installation, you don’t trust the script or it simply don’t work for you. Go to https://caddyserver.com/download.

After configuring your installation your can see at the bottom of the page the generated URL to download caddy’s binaries.

For my configuration it give me this :

Download it then extract it and install it :

tar -xzf caddy*.tar.gz caddymv ./caddy /usr/local/bin

Verify your installation with :

Setting up Caddy and systemd Service Unit

sudo setcap ‘cap_net_bind_service=+ep’ /usr/local/bin/caddy

Now let’s create the necessary directories.

Create a directory where you will store Caddy’s configuration files:

sudo mkdir /etc/caddysudo chow -R root:www-data /etc/caddy

Later in this tutorial we will configure automatic TLS with Let’s Encrypt. That’s why we need make a directory to store any TLS certificates that caddy with obtain:

sudo mkdir /etc/ssl/caddysudo chown -R root:www-data /etc/ssl/caddysudo chmod 0770 /etc/ssl/caddy

Caddy is configured with a file called Caddyfile, the systemd service for Caddy will expect this file to be stored in /etc/caddy so create your caddy configuration file and give it appropriate ownership and permissions:

sudo touch /etc/caddy/Caddyfilesudo chown www-data:www-data /etc/caddy/Caddyfilesudo chmod 444 /etc/caddy/Caddyfile

and add :

Create the home directory for the server and set the appropriate permissions and ownership

sudo mkdir /var/wwwsudo chown www-data:www-data /var/wwwsudo chmod 555 /var/www

Download the systemd service unit configuration file :

Then copy it to the systemd directory and set the appropriate permissions and ownership:

sudo cp caddy.service /etc/systemd/systemsudo chow root:root /etc/systemd/system/caddy.servicesudo chmod 644 /etc/systemd/system/caddy.service

Reload the daemon and start the service :

sudo systemctl daemon-reloadsudo systemctl start caddy.service

You can have the caddy service start automatically on boot :

sudo systemctl enable caddy.service

To monitor caddy you can use this command which will show you the latest logs from caddy:

journatcl -f -u caddy.server

Done! Open your browser and test your website !

If you see a 404 error , then Caddy is working, but you forgot to add an index file to your website directory.

Next, you can explore the Caddy documentation to install plugins or achieve more complex things.

Web servers help us to manage and scale our web apps in production. They have been the mysterious part of the stack to some web developers. It’s because configuring a web server is fairly time consuming for first timers as they need to know how reverse-proxies work and also have to deal with quirky config files.

But thanks to Caddy. It removes complexity surrounding the webservers. Developers who have used Caddy know the drill. Download a binary file, write few lines of config, start the binary by pointing it to the config file. Now you will have a secure web server running as caddy takes care of SSL by itself.

We know that CaddyServer is simple. But do you know that it’s extensible too? Yes, you can import caddy as library and embed the web server inside your Go code.

When the web server is embedded into the code, we get more control over it. Adding a battle tested web server into your code allows you to use your code as reverse-proxy with graceful restarts or even for load balancing.

Today you will learn how to use caddy server as library in Go code. We will build a simple web app that runs on port 8000 and route all the requests hitting port 80 to it using caddy server as library.

High level representation of what we are going to build

A basic Caddyfile looks like this when you reverse proxy a web service running on port 8000 to the port 80.

:80proxy / localhost:8000

Now let’s start building our components one by one.

Simple HTTP server

We will write a dead simple HTTP server using mux router that exposes an endpoint /ping.

A simple http server using mux router

Visiting the URL localhost:8000/ping in browser after running the above code should output this.

Now we have got our HTTP server up and running. Let us first proxy it through port 80 using standalone caddy server manually. The Caddyfile will look like this.

Start the Caddy server by pointing it to the Caddyfile.

./caddy —conf Caddyfile

If both HTTP server and this caddy server is running, opening localhost:80/ping in the browser will route requests to localhost:8000/ping and give you the text response.

Embedding a basic caddy server

We will replace the standalone caddy server in above step with an embedded server. In order to do that, first we need to install caddy as a library by doing go get github.com/mholt/caddy.

Here’s the code to embed a basic version of caddy server.

Basic example as seen in official wiki page.

Inside main() we first set the AppName and AppVersion for our caddy instance.

⚠️ We are setting up server type as http, so we have to make sure server type package_ «github.com/mholt/caddy/caddyhttp» is imported, else code will panic.

Running the above code spits this output.

Caddy says the server has been started on port 2015. If you goto localhost:2015 you should get a 404 error from caddy server as there is no upstream connected to that port.

404 error returned from our caddy server

Now we have confirmed that the caddy server is running as library. It’s time to make use of it by reverse-proxying an upstream server, the simple HTTP server we initially built.

Reading caddy config file

We can make the previous snippet to read the config from Caddyfile by adding couple of functions to it. loadConfig() function to read the contents of the caddy config file and init() to tell caddy which function to use inorder to load the config file.

The loadConfig() function assembles the CaddyfileInput struct by accepting contents of the Caddyfile, it’s Filepath and serverType. The ServerTypeName and Contents are important fields of the struct where as Filepath is just for logging or reference purpose.

Inside init() you tell the caddy server to use the function loaderConfig() to prepare the CaddyfileInput. When you run this snippet, it proxies the http port: port 80 to the port 8000. But before doing that we need to start our upstream HTTP server by running the snippet simpleHTTPServer.go.

Now all your requests to localhost:80 are proxied to the upstream server running on localhost:8000. Hitting /ping endpoint returns the response served from the upstream server.

‘/ping’ API served on port 80 from upstream server

Playing around with the code

The snippets have been wrapped into its own packages in this repository.

Clone the repository and cd to embed_caddy folder. The code structure there should look like this:

I have used Glide as a package manager here. So, install glide by doing brew install glide. If you’re not on macOS, do go get github.com/Masterminds/glide.

Install the dependencies by running glide install from inside the embed_caddy folder. Now you are ready to build and run the code.

Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

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

Часто такой веб-сервер либо встроен в сам язык как модуль, либо написан на этом же языке, для запуска кода внутри себя. Обычно, задачу интеграции берут на себя фреймворки. В нашем приложении devops-example-app за это отвечает фреймворк fastify. Внутри себя он использует встроенный в Node.js веб-сервер:

Несмотря на простоту такой схемы, ее в большинстве проектов недостаточно. Помимо встроенного веб-сервера, нужен внешний, выполняющий роль реверс-прокси (reverse-proxy), например Nginx или Caddy.

Прокси-сервер ставится между клиентами и внутренней инфраструктурой. Он принимает запросы от клиентов и переадресует их на внутренний веб-сервер или веб-сервера, если их много. Именно поэтому он называется реверс (обратный), снаружи внутрь. Зачем он нужен?

• Проекты редко состоят только из кода, который мы запускаем на встроенном веб-сервере. Помимо кода, почти всегда есть файлы, css, js, картинки и другие файлы. Для их «раздачи» тоже нужен веб-сервер, а еще нужно уметь их сжимать и кешировать
• Далеко не все внутренние веб-сервера умеют эффективно обрабатывать «медленных клиентов». Это клиенты с медленным соединением, которые очень долго отправляют и принимают данные. Они занимают ресурсы веб-сервера и приложения. Если придет достаточное количество медленных клиентов, то веб-сервер и приложение быстро перестанут отвечать. Пользователи начнут видеть ошибки
• Встроенные веб-сервера достаточно ограниченны в своих возможностях, например в том как они обрабатывают ошибки, как поддерживают HTTPS и так далее

Эти причины настолько серьезны, что без реверс-прокси в продакшен не ходят. Только какой выбрать? Nginx самый популярный сервер в мире, но Caddy, гораздо проще в настройке и отладке. У него встроенная поддержка Let’s Encrypt, Caddy автоматически обновляет сертификаты для работы HTTPS. Поэтому в этом курсе мы воспользуемся Caddy. Изучив его, вы без труда сможете перейти на Nginx, так как концептуально все подобные веб-сервера работают одинаково.

Для начала Caddy нужно подключить к локальной разработке. Так мы сможем тестировать его конфигурацию еще до выкладки в продакшен.

Локальное окружение

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

Добавим Docker Compose с такой конфигурацией:

# file: docker-compose.yml

# Имя сервиса

# Контекст для сборки образа,
# в данном случае, текущая директория

# Имя Docker-файла из которого будет собран образ

# Находится внутри services/caddy

Почему именно так? Мы придерживаемся структуры, в которой основное приложение располагается в корне проекта, а дополнительные сервисы лежат в директории services. У каждого сервиса своя директория с Dockerfile внутри.

# У Caddy есть официальный образ, но его недостаточно
# В продакшене конфигурация должна быть частью образа
# Поэтому мы делаем свой образ, в который «зашиваем» конфигурацию
FROM caddy

# Конфигурационный файл Caddy
# Читается из /etc/caddy/Caddyfile
COPY services/caddy/Caddyfile /etc/caddy/

# Копируем приложение для доступа к статическим файлам хранящимся в репозитории
# Обычно это элементы интерфейса
COPY /app

Там же хранятся дополнительные файлы конкретного сервиса. Например у Caddy это файл Caddyfile, в котором содержится конфигурация:

После того как все файлы добавлены, можно запустить проект локально и убедиться что он работает:

После этого запрос к localhost пойдет в Caddy, который выполнит автоматическое перенаправление на https. Браузер укажет на недоверенный сертификат, что нормально, так как он самоподписной. Все что остается сделать, чтобы увидеть сайт — подвердить что вы согласны с риском.

Продакшен

Первым делом добавим Caddy в сборку на коммит. Для этого создадим репозиторий для Caddy на Docker Hub и расширим воркфлоу main.yml:

# Добавляем сразу после сборки app
Build and push caddy

# Не забудьте создать репозиторий в Docker Hub

Следующим шагом добавим в релиз:

# Добавляем сразу после сборки app
docker pull hexletcomponents/devops-example-caddy:latest

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

Если просто добавить старт контейнера в плейбук ansible/deploy.yml, то сайт не откроется. Caddy попытается обратиться к указанному в конфигурации app:3000 и выдаст в лог ошибку о недоступности домена. Почему? Каждый контейнер в Docker запускается в изолированной среде и не знает про другие контейнеры. Для их связи используется network.

# Создаем общую сеть
# Контейнеры добавленные в эту сеть, могут обращаться друг к другу по имени контейнера,
# который становится dns именем

# имя используется как домен

# Добавляем контейнер в сеть

# Больше не нужно выставлять наружу, потому что доступ идет через Caddy
# — 3000:3000

# имя используется как домен

# Добавляем контейнер в сеть

Когда все добавлено, выполните деплой последнего релиза:

ansible-playbook release.yml inventory.yml

# Укажите тут адрес вашей машины, которую вы создали
65.108.149.193 devops-example.test

Попробуйте открыть в браузере devops-example.test. Если все было сделано правильно, то вы увидите сайт.

Обработка ошибок

Во время деплоя приложение перезапускается. Между остановкой и стартом новой версии проходит какое-то время, когда приложение не работает, а пользователи видят ошибку 502 Bad Gateway. Иногда это время достаточно большое, есть приложения которые стартуют минуты.

Обработка ошибки 502 задача реверс-прокси. Для этого создается html-файл, в котором красиво описывается ситуация «мы обновляемся». Этот файл добавляется в образ к веб-серверу, а в конфигурации прописываются такие строки:

Чаще стал встречать в сети небольшие сайты-визитки или лендинги, разработанные в визуальных html/графических-редакторах типа Adobe Dreamviewer, Microsoft FrontPage или Adobe Muse СС.

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

Для удобства тестирования и размещения html-сайтов помимо самого популярного веб-сервера apache можно использовать другие веб-серверы: nginx, lighttpd, cheerokee, iis. Но наиболее удачным вариантом я считаю Caddy. Самые существенные плюсы этого веб-сервера: мультиплатформенность и запуск без конфигурационного файла в директории с файлами сайта.

Рассмотрим подробнее функционал Caddy и примеры запуска:

• Шифрование TLS .12 с использованием своих ключей и сертификатов
• Простое внедрение и использование. Требуется только один файл. Отсутствие зависимостей
• Не требует установки
• Поддержка мультиядерности/мультипроцессорности
• Технология веб-сокетов — создание интерактивной сессии между браузером и сервером
• Полная поддержка IPv6
• Настройка формата ведения лог-файлов
• FastCGI, Реврайты, редиректы, ЧПУ, gzip-сжатие, виртуальные хосты, вывод списка файлов в директории, реверс-проксирование
• Мультиплатформенность: Windows, Linux, BSD, Mac, Android

Чтобы запустить веб-сервер, скачиваем со страницы загрузки под вашу ОС https://caddyserver.com/download.