Настройка nginx proxy 1с
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
80 contributors
Users who have contributed to this file
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
nginx-proxy sets up a container running nginx and docker-gen. docker-gen generates reverse proxy configs for nginx and reloads nginx when containers are started and stopped.
See Automated Nginx Reverse Proxy for Docker for why you might want to use this.
The containers being proxied must expose the port to be proxied, either by using the EXPOSE directive in their Dockerfile or by using the --expose flag to docker run or docker create and be in the same network. By default, if you don't pass the --net flag when your nginx-proxy container is created, it will only be attached to the default bridge network. This means that it will not be able to connect to containers on networks other than bridge.
The nginx-proxy images are available in two flavors.
This image uses the debian:buster based nginx image.
This image is based on the nginx:alpine image. Use this image to fully support HTTP/2 (including ALPN required by recent Chrome versions). A valid certificate is required as well (see eg. below "SSL Support using an ACME CA" for more info).
You can activate the IPv6 support for the nginx-proxy container by passing the value true to the ENABLE_IPV6 environment variable:
Scoped IPv6 Resolvers
NginX does not support scoped IPv6 resolvers. In docker-entrypoint.sh the resolvers are parsed from resolv.conf, but any scoped IPv6 addreses will be removed.
By default, docker uses IPv6-to-IPv4 NAT. This means all client connections from IPv6 addresses will show docker's internal IPv4 host address. To see true IPv6 client IP addresses, you must enable IPv6 and use ipv6nat. You must also disable the userland proxy by adding "userland-proxy": false to /etc/docker/daemon.json and restarting the daemon.
When your container exposes only one port, nginx-proxy will default to this port, else to port 80.
If you need to specify a different port, you can set a VIRTUAL_PORT env var to select a different one. This variable cannot be set to more than one port.
For each host defined into VIRTUAL_HOST , the associated virtual port is retrieved by order of precedence:
- From the VIRTUAL_PORT environment variable
- From the container's exposed port if there is only one
- From the default port 80 when none of the above methods apply
The full request URI will be forwarded to the serving container in the X-Forwarded-Path header.
NOTE: Your application needs to be able to generate links starting with VIRTUAL_PATH . This can be achieved by it being natively on this path or having an option to prepend this path. The application does not need to expect this path in the request.
This environment variable can be used to rewrite the VIRTUAL_PATH part of the requested URL to proxied application. The default value is empty (off). Make sure that your settings won't result in the slash missing or being doubled. Both these versions can cause troubles.
If the application runs natively on this sub-path or has a setting to do so, VIRTUAL_DEST should not be set or empty. If the requests are expected to not contain a sub-path and the generated links contain the sub-path, VIRTUAL_DEST=/ should be used.
Per-VIRTUAL_PATH location configuration
The same options as from Per-VIRTUAL_HOST location configuration are available on a VIRTUAL_PATH basis. The only difference is that the filename gets an additional block HASH=$(echo -n $VIRTUAL_PATH | sha1sum | awk '< print $1 >') . This is the sha1-hash of the VIRTUAL_PATH (no newline). This is done filename sanitization purposes. The used filename is $_$_location
The filename of the previous example would be example.tld_8610f6c344b4096614eab6e09d58885349f42faf_location .
This environment variable of the nginx proxy container can be used to customize the return error page if no matching path is found. Furthermore it is possible to use anything which is compatible with the return statement of nginx.
For example DEFAUL_ROOT=418 will return a 418 error page instead of the normal 404 one. Another example is DEFAULT_ROOT="301 https://github.com/nginx-proxy/nginx-proxy/blob/main/README.md" which would redirect an invalid request to this documentation. Nginx variables such as $scheme, $host, and $request_uri can be used. However, care must be taken to make sure the $ signs are escaped properly. If you want to use 301 $scheme://$host/myapp1$request_uri you should use:
- Bash: DEFAULT_ROOT='301 $scheme://$host/myapp1$request_uri'
- Docker Compose yaml: - DEFAULT_ROOT: 301 $$scheme://$$host/myapp1$$request_uri
With the addition of overlay networking in Docker 1.9, your nginx-proxy container may need to connect to backend containers on multiple networks. By default, if you don't pass the --net flag when your nginx-proxy container is created, it will only be attached to the default bridge network. This means that it will not be able to connect to containers on networks other than bridge .
If you want your nginx-proxy container to be attached to a different network, you must pass the --net=my-network option in your docker create or docker run command. At the time of this writing, only a single network can be specified at container creation time. To attach to other networks, you can use the docker network connect command after your container is created:
In this example, the my-nginx-proxy container will be connected to my-network and my-other-network and will be able to proxy to other containers attached to those networks.
Internet vs. Local Network Access
If you allow traffic from the public internet to access your nginx-proxy container, you may want to restrict some containers to the internal network only, so they cannot be accessed from the public internet. On containers that should be restricted to the internal network, you should set the environment variable NETWORK_ACCESS=internal . By default, the internal network is defined as 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 . To change the list of networks considered internal, mount a file on the nginx-proxy at /etc/nginx/network_internal.conf with these contents, edited to suit your needs:
If you would like to connect to uWSGI backend, set VIRTUAL_PROTO=uwsgi on the backend container. Your backend container should then listen on a port rather than a socket and expose that port.
If you would like to connect to FastCGI backend, set VIRTUAL_PROTO=fastcgi on the backend container. Your backend container should then listen on a port rather than a socket and expose that port.
FastCGI File Root Directory
If you use fastcgi,you can set VIRTUAL_ROOT=xxx for your root directory
nginx-proxy will then redirect all requests to a container where VIRTUAL_HOST is set to DEFAULT_HOST , if they don't match any (other) VIRTUAL_HOST . Using the example above requests without matching VIRTUAL_HOST will be redirected to a plain nginx instance after running the following command:
nginx-proxy can also be run as two separate containers using the nginxproxy/docker-gen image and the official nginx image.
You may want to do this to prevent having the docker socket bound to a publicly exposed container service.
You can demo this pattern with docker-compose:
To run nginx proxy as a separate container you'll need to have nginx.tmpl on your host system.
First start nginx with a volume:
Then start the docker-gen container with the shared volume and template:
Finally, start your containers with VIRTUAL_HOST environment variables.
SSL Support using an ACME CA
acme-companion is a lightweight companion container for the nginx-proxy. It allows the automated creation/renewal of SSL certificates using the ACME protocol.
SSL is supported using single host, wildcard and SNI certificates using naming conventions for certificates or optionally specifying a cert name (for SNI) as an environment variable.
If you are running the container in a virtualized environment (Hyper-V, VirtualBox, etc. ), /path/to/certs must exist in that environment or be made accessible to that environment. By default, Docker is not able to mount directories on the host machine to containers running in a virtual machine.
RFC7919 groups with key lengths of 2048, 3072, and 4096 bits are provided by nginx-proxy . The ENV DHPARAM_BITS can be set to 2048 or 3072 to change from the default 4096-bit key. The DH key file will be located in the container at /etc/nginx/dhparam/dhparam.pem . Mounting a different dhparam.pem file at that location will override the RFC7919 key.
COMPATIBILITY WARNING: The default generated dhparam.pem key is 4096 bits for A+ security. Some older clients (like Java 6 and 7) do not support DH keys with over 1024 bits. In order to support these clients, you must provide your own dhparam.pem .
In the separate container setup, no pre-generated key will be available and neither the nginxproxy/docker-gen image, nor the offical nginx image will provide one. If you still want A+ security in a separate container setup, you should mount an RFC7919 DH key file to the nginx container at /etc/nginx/dhparam/dhparam.pem .
Set DHPARAM_SKIP environment variable to true to disable using default Diffie-Hellman parameters. The default value is false .
To enable OCSP Stapling for a domain, nginx-proxy looks for a PEM certificate containing the trusted CA certificate chain at /etc/nginx/certs/.chain.pem , where is the domain name in the VIRTUAL_HOST directive. The format of this file is a concatenation of the public PEM CA certificates starting with the intermediate CA most near the SSL certificate, down to the root CA. This is often referred to as the "SSL Certificate Chain". If found, this filename is passed to the NGINX ssl_trusted_certificate directive and OCSP Stapling is enabled.
How SSL Support Works
The default SSL cipher configuration is based on the Mozilla intermediate profile version 5.0 which should provide compatibility with clients back to Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, and Safari 9. Note that the DES-based TLS ciphers were removed for security. The configuration also enables HSTS, PFS, OCSP stapling and SSL session caches. Currently TLS 1.2 and 1.3 are supported.
If you don't require backward compatibility, you can use the Mozilla modern profile profile instead by including the environment variable SSL_POLICY=Mozilla-Modern to the nginx-proxy container or to your container. This profile is compatible with clients back to Firefox 63, Android 10.0, Chrome 70, Edge 75, Java 11, OpenSSL 1.1.1, Opera 57, and Safari 12.1. Note that this profile is not compatible with any version of Internet Explorer.
Other policies available through the SSL_POLICY environment variable are Mozilla-Old and the AWS ELB Security Policies AWS-TLS-1-2-2017-01 , AWS-TLS-1-1-2017-01 , AWS-2016-08 , AWS-2015-05 , AWS-2015-03 and AWS-2015-02 .
Note that the Mozilla-Old policy should use a 1024 bits DH key for compatibility but this container provides a 4096 bits key. The Diffie-Hellman Groups section details different methods of bypassing this, either globally or per virtual-host.
The default behavior for the proxy when port 80 and 443 are exposed is as follows:
Note that in the latter case, a browser may get an connection error as no certificate is available to establish a connection. A self-signed or generic cert named default.crt and default.key will allow a client browser to make a SSL connection (likely w/ a warning) and subsequently receive a 500.
Basic Authentication Support
In order to be able to secure your virtual host, you have to create a file named as its equivalent VIRTUAL_HOST variable on directory /etc/nginx/htpasswd/$VIRTUAL_HOST
You'll need apache2-utils on the machine where you plan to create the htpasswd file. Follow these instructions
Custom Nginx Configuration
If you need to configure Nginx beyond what is possible using environment variables, you can provide custom configuration files on either a proxy-wide or per- VIRTUAL_HOST basis.
Replacing default proxy settings
If you want to replace the default proxy settings for the nginx container, add a configuration file at /etc/nginx/proxy.conf . A file with the default settings would look like this:
NOTE: If you provide this file it will replace the defaults; you may want to check the .tmpl file to make sure you have all of the needed options.
To add settings on a proxy-wide basis, add your configuration file under /etc/nginx/conf.d using a name ending in .conf .
This can be done in a derived image by creating the file in a RUN command or by COPY ing the file into conf.d :
Or it can be done by mounting in your custom configuration in your docker run command:
To add settings on a per- VIRTUAL_HOST basis, add your configuration file under /etc/nginx/vhost.d . Unlike in the proxy-wide case, which allows multiple config files with any name ending in .conf , the per- VIRTUAL_HOST file must be named exactly after the VIRTUAL_HOST .
In order to allow virtual hosts to be dynamically configured as backends are added and removed, it makes the most sense to mount an external directory as /etc/nginx/vhost.d as opposed to using derived images or mounting individual configuration files.
Per-VIRTUAL_HOST default configuration
If you want most of your virtual hosts to use a default single configuration and then override on a few specific ones, add those settings to the /etc/nginx/vhost.d/default file. This file will be used on any virtual host which does not have a /etc/nginx/vhost.d/ file associated with it.
Per-VIRTUAL_HOST location configuration
To add settings to the "location" block on a per- VIRTUAL_HOST basis, add your configuration file under /etc/nginx/vhost.d just like the previous section except with the suffix _location .
Per-VIRTUAL_HOST location default configuration
If you want most of your virtual hosts to use a default single location block configuration and then override on a few specific ones, add those settings to the /etc/nginx/vhost.d/default_location file. This file will be used on any virtual host which does not have a /etc/nginx/vhost.d/_location file associated with it.
Per-VIRTUAL_HOST server_tokens configuration
Unhashed vs SHA1 upstream names
By default the nginx configuration upstream blocks will use this block's corresponding hostname as a predictable name. However, this can cause issues in some setups (see this issue). In those cases you might want to switch to SHA1 names for the upstream blocks by setting the SHA1_UPSTREAM_NAME environment variable to true on the nginx-proxy container.
Please note that using regular expressions in VIRTUAL_HOST will always result in a corresponding upstream block with an SHA1 name.
In case you can't access your VIRTUAL_HOST, set DEBUG=true in the client container's environment and have a look at the generated nginx configuration file /etc/nginx/conf.d/default.conf :
Especially at upstream definition blocks which should look like:
The effective Port is retrieved by order of precedence:
- From the VIRTUAL_PORT environment variable
- From the container's exposed port if there is only one
- From the default port 80 when none of the above methods apply
Before submitting pull requests or issues, please check github to make sure an existing issue or pull request is not already open.
Running Tests Locally
To run tests, you just need to run the command below:
This commands run tests on two variants of the nginx-proxy docker image: Debian and Alpine.
You can run the tests for each of these images with their respective commands:
You can learn more about how the test suite works and how to write new tests in the test/README.md file.
Зачем нужен обратный прокси
Обратный прокси выполняет одну из важнейших функций — применяет ко всем внешним подключениям определенные политики. Это может быть распределение, в зависимости от запрашиваемого имени, балансировка нагрузки, отдача статического содержимого из определенных каталогов, а также точка терминирования SSL соединений. На обратном прокси может располагаться wildcart сертификат, несколько простых сертификатов или сертификат на несколько имен. Все соединения между прокси и клиентами будут зашифрованы этим сертификатом, а на бекэнд серверах со службами можно будет не беспокоиться о настройке SSL и сроках действия сертификатов. Таким образом, с определенного момента, наличие обратного прокси снижает стоимость и увеличивает эффективность поддержки SSL на веб-серверах.
Опубликованные базы 1С, также, как и другие веб приложения, могут работать через обратный прокси. В этом случае веб-сервер IIS или apache, с помощью которого публикуется база, может работать без настройки SSL в качестве бекэнд сервера, а обратный прокси, в роли которого применен nginx, терминирует ssl соединения к внешнему адресу из интернета и передает запрос на этот бекэнд. Бекэнд обрабатывает запрос и возвращает его обратно, через прокси сервер. Отдаваемый ответ оборачивается в SSL и возвращается клиенту. Так работает схема в общих чертах.
Если в сети имеется еще один веб-сервер, на котором находятся еще опубликованные базы 1С или любое другое веб-приложение и его необходимо опубликовать в интернет, можно добавить дополнительное доменное имя, сертификат для него и дополнить настройку nginx. Таким образом на одном внешнем IP адресе, на одном стандартном порту, могут начать работать два и более сайта с разными доменными именами.
Также путем редактирования локаций можно распределять запросы к одному доменному имени по разным серверам на основании запрашиваемых данных. Преимущество в том, что эта настройка всегда будет находиться в одном месте, рядом с сертификатами и может, как любой текстовый файл, храниться в системе управления версиями.
Развертывание прокси
Для развертывания сервисов, таких как обратный прокси, очень хорошо зарекомендовал себя docker. Для запуска этого сервиса использован стек docker-compose, состоящий из 2 контейнеров — самого веб-сервера nginx и certbot для получения и обновления SSL-сертификатов:
Здесь все обычно — порты, тома, настройки. Единственное, что отличается — команда запуска. Об этом поясняется далее. Обязательно нужно предусмотреть доступ на этот сервер из интернета по 80 порту, это необходимо при получении SSL сертификата.
Получение SSL сертификата
Для того, чтобы запустить все в работу нужен SSL сертификат, но чтобы получить сертификат, необходимо запуститься. Эту проблему решает запуск скрипта init-letsencrypt.sh перед первым запуском всего приложения. Предварительно в скрипт необходимо внести изменения — перечислить домены, на которые получается сертификат. После запуска будет произведен выпуск сертификатов и запуск приложения. Если все проделано правильно, то после выполнения можно будет заходить на сайты, описанные в конфиге nginx/nginx.conf. Пример описания одного виртуального сервера из него:
Применение к публикациям 1С
Для этого необходимо на nginx всего лишь выполнить следующие настройки, а затем применить их, попросив веб-сервер перечитать свой файл конфигурации. Допустим, что изменения в файл init-letsencrypt.sh уже внесены и сертификат обновлен, теперь необходимо настроить и перезапустить nginx. В файл nginx/nginx.conf необходимо добавить секцию сервера:
После внесения изменений необходимо выполнить команду:
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный теcт.
Введение
Допустим, у вас небольшой рабочий коллектив и вам нужно работать с базами 1С. Одновременно там будет работать 2-3 человека, редко 5. В общем, в этих пределах. Вам надо купить как минимум 5 софтовых лицензий для сотрудников. Но куда их ставить, если у каждого сотрудника свой компьютер, а сервер терминалов поднимать не было в ваших планах. Во-первых, он денег стоит, во-вторых, его надо настраивать, обслуживать, защищать от угроз извне, если доступ будет по rdp. В общем, на маленьких масштабах это пушкой по воробьям. Чего уж говорить о клиент серверной установке 1С с использованием сервера баз данных mssql или postgresql. Для небольших компаний это перебор как по цене, так и функционалу. Я предлагаю решение значительно проще.
На помощь приходит публикация баз 1С на веб сервере с доступом пользователей через браузер. Лицензии ставятся на один компьютер. На него устанавливается веб сервер, публикуются базы 1С и настраивается доступ. Пользователям достаточно будет передать только ссылку для работы в базах. Это удобная схема работы, плюс в целом быстродействие файловых баз при одновременной работе нескольких пользователей будет выше. Ко всему прочему еще и пользователям на компьютер не нужно ставить платформу и обновлять ее.
Схема установки
Я предлагаю следующую схему работы с базами 1С при их публикации. Доступ нужен будет отовсюду через интернет. Для этого арендуется выделенный сервер, например в selectel. Достаточно будет сервера примерно за 4000р. с 2 ssd дисками и 32g оперативной памяти. Туда ставится гипервизор proxmox. И настраиваются минимум 3 виртуальные машины:
Это минимальный набор виртуалок. Сюда же можно добавить мониторинг либо еще какой-то сервис, необходимый вашей компании. Например чат или ip телефония. Производительности дедика хватит для небольшой компании.
Публикация баз 1С на веб сервере
Идем на виртуалку с windows и работаем там с 1С. Кстати, если хотите обойтись вообще без windows, то есть возможность настроить публикацию баз 1С на linux на примере Centos.
Для начала устанавливаем технологическую платформу и не забываем выбрать Модули расширения веб-сервера.
Создаем там необходимую вам базу данных. Я покажу на примере публикации типовой базы Бухгалтерия 3.0. При первом запуске необходимо будет установить на этот компьютер софтовые лицензии. Они будут использоваться при доступе к базам через браузер.
Установка и настройка Apache 2.4 в Windows
Если вы настраиваете apache на Windows Server, то скорее всего 80-й порт у вас будет занимать Служба веб-публикаций (World Wide Web Publushing Service) или W3SVC. Ее можно остановить и отключить.
Для того, чтобы точно узнать, кто занимает тот или иной порт в Windows, можно воспользоваться командой в консоли:
Дальше через диспетчер задач смотрите, какой процесс имеет указанный pid. В моем случае это apache. Если это какой-то системный процесс, у него будет pid 4.
Итак, конфиг apache отредактировали, порт 80 указали. Теперь установим apache 2.4 как службу windows. Для этого открываем командную строку от администратора (это важно), переходим в каталог C:\Apache24\bin и выполняем:
Вы можете увидеть ошибку, связанную с отсутствием fqdn имени у сервера. Но реально это не представляет проблемы, можно игнорировать.
Переходим в оснастку windows Службы и запускаем Apache2.4.
Дальше выполняем непосредственно публикацию базы 1С через web сервер apache. Открываем базу через Конфигуратор, выбираем Администрирование -> Публикация на веб-сервере. В качестве каталога можно указать тот же, где лежит сам файл с базой.
Все настройки можно оставлять дефолтными. Сохраняем изменения. После этого должен быть выполнен перезапуск службы apache автоматически. Но если платформа была запущена не от администратора, то у нее не хватит прав это сделать. Надо сходить в Службы и перезапустить вручную.
Теперь с ней можно работать через браузер, но пока только с этого компьютера, либо по локальной сети. Далее сделаем так, чтобы доступ был и через интернет.
Доступ к файловой базе 1с через интернет в браузере
На данную виртуальную машину должны быть проброшены 80 и 443 порты с внешнего ip адреса. Как это будет сделано, зависит от ваших сетевых настроек. В случае с proxmox я настраиваю подобный проброс с самого хоста с помощью iptables. Пример настройки iptables читайте в отдельной статье. Там есть и про проброс. Не буду на этом задерживаться в статье про 1С.
Теперь нам нужно получить сертификат. Для этого запускайте в консоли certbot и следуйте инструкциям. Перед этим остановите nginx. Для быстрого получения сертификата certbot предлагает временно запустить свой веб сервер на 80-м порту.
В данном случае 10.10.10.11 - локальный ip адрес виртуальной машины с windows, где опубликована база 1С через apache. Доступ к 1С сразу же закрыт отдельным паролем и механизмом веб сервера auth basic. Создадим файл с именем пользователя и паролем, указанным в конфиге.
Вот и все. Можно относительно безопасно выставлять такую конструкцию в интернет. В случае необходимости можно настроить fail2ban, если кто-то надумает перебирать пароли или просто выполнять непонятные запросы к веб серверу с опубликованными базами. При желании в том же nginx с помощью директив allow и deny можно ограничить доступ к виртуальному хосту с базами на уровне ip адресов. Это на случай, если не умеете делать то же самое на фаерволе. В nginx проще и быстрее.
Не забудьте настроить автоматическое обновление tls сертификатов. Как это сделать, я рассказываю в статье с настройкой web сервера. Ссылку на нее я дал выше.
Какие бывают проблемы с работой в 1С через браузер
В таком режиме у меня уже пару лет работают несколько серверов с 1С. Иногда возникают нюансы с доступом через браузер. Например, не настроить обмен между базами, не зная их локальных путей. Бухгалтера сами его не смогут настроить. Им нужно будет передать информацию по директориям с базами. Понятное дело, что и обновить платформу они сами не смогут, так как нужно будет обновлять и публикацию баз. Когда вы сами подключены через браузер, сделать это невозможно.
Так что некоторые вещи, которые обычно бухгалтера в небольших компаниях способны сделать сами, придется делать тому, кто обслуживает этот сервер. Но бонусом идет то, что на самих пользовательских компьютерах ничего настраивать не надо. Вы просто передаете пользователю адрес в интернете и учетные данные. И он начинает работать в базе 1с. Платформу ставить не надо, как и решать вопрос с лицензиями на клиентах.
Сделать это надо в cmd с правами администратора. И повторять каждый раз при обновлении платформы, не забывая указать путь к новой версии файла.
Ошибка совершенно не гуглится, так что потратил много времени на ее решение. Помог режим отладки в chrome. Я просто проверил все запросы и нашел ошибочные с кривыми урлами. И так и сяк пытался их решить редиректами на веб серверах, но в итоге пришлось в apache переехать на 80-й порт и ошибка ушла.
Ну и еще одно отмечу. Иногда apache зависает или начинает сильно тупить. Обычно после долгого аптайма в несколько недель. Я подробно не разбирался в проблеме. Предпочел просто перезапускать его раз в сутки ночью. Для этого сделал обычный bat файл и настроил запуск через планировщик Windows.
Понятно, что это грубый костыль, но проблему решает. Ночью все равно с 1С никто не работает. Это история не про отказоустойчивость, резервирование и работу 7/24/365.
Подключение через Платформу 1С:Предприятие к базе 1С, опубликованной в веб
Упомяну одну важную вещь, про которую я сам узнал не сразу. С опубликованной в web базой 1С не обязательно работать через браузер. Можно подключиться через обычную платформу, если она у вас установлена на компьютере. Причем все отлично заработает даже с дополнительной basic auth в виде еще одной авторизации.
Чтобы добавить такую базу в платформу, достаточно указать, что тип расположения информационной базы - веб-сервер.
При подключении к такой базе вам сначала нужно будет ввести пароль на доступ к веб сайту, а потом уже появится авторизация самой 1С. Удобно выходит. И субъективно кажется, что через платформу 1С работать с опубликованной базой немного быстрее. Быстрее отклик на действия пользователя.
Бэкап баз 1С
Для полноты картины расскажу, как легко и быстро забэкапить файловые базы 1С. Пошаговую инструкцию не буду писать, так как у всех свои ситуации и каждый делает по-своему. Я на словах расскажу, как можно поступить с архивными копиями. Сам я каждый раз придумываю разные решения для бэкапов 1С в зависимости от обстоятельств.
Для меня важно держать где-то недалеко от рабочего сервера несколько архивных копий баз, чтобы их можно было оперативно загрузить на сервер и работать с ними. Для этого у меня на этом же гипервизоре отдельная виртуальная машина исключительно для бэкапов. Доступ к ней максимально ограничен. Она сама забирает все бэкапы к себе. С windows машины к ней доступа нет. Сделано это для простейшей защиты от шифровальщиков. Если какой-то вирус попадет на сервер и зашифрует базы 1С, я очень быстро смогу их восстановить из архивных копий, которые хранятся на этом же гипервизоре, только в другой виртуальной машине.
На windows сервере можно просто расшарить директорию с базами 1С, а на виртуалке для бэкапов подключить ее. Я обычно использую Linux систему для этого. В ней монтирую шару по smb. Как это сделать рассказываю в отдельной статье - Как быстро подмонтировать сетевой диск в Linux. После того, как подключили папку с базами 1С к бэкап серверу, можете делать с ними все, что угодно. Например, куда-то копировать с помощью rsync и сохранять изменившиеся базы. Подробно схему бэкапов с помощью rsync описываю тоже отдельно - настройка rsync для бэкапа. Обязательно одну копию держу локально на сервере с бэкапами, вторую отправляю куда-то в удаленный приемник. После этого шару отмонтирую. Она подключена только для копирования баз с windows машины на linux.
Так же для бэкапов вы можете использовать какое-нибудь S3 хранилище, например у того же Selectel. По моим недавним сравнениям по ценам там наиболее выгодные условия из известных хостеров. По крайней мере я дешевле не нашел. Заливать бэкапы в S3 можно с помощью утилиты rclone. У Selectel еще очень удобно сделано в плане настройки времени хранения данных в контейнерах. Я обычно создаю 3 разных контейнера:
- Day - в него заливаются архивы каждый день. Срок хранения файлов в этом контейнере - 7 дней. Настраивается это штатно в панели управления. На стороне хоста, с которого заливаются данные, ничего делать не надо.
- Week - архивы заливаются раз в неделю и хранятся 31 день.
- Month - архивы заливаются раз в месяц и хранятся условно бесконечно.
Таким образом мы просто каждый день льем файлы в S3 в разные контейнеры, а там они автоматом ротируются. Мы всегда имеем 7 последних копий, 4 недельные и помесячные. Удобная схема и не очень дорогая. Стоимость хранения можете сами прикинуть по калькулятору хранилища.
Еще один вариант бэкапа - копировать базы по nfs на какой-то сервер. В общем, тут вариантов может быть очень много. Я для этого и использую такую схему - подключение директории с базами к linux серверу, а там уже возможности по работе с бэкапами безграничные. Можно на тот же Яндекс.Диск их передавать. Вот тоже статья по этому поводу - бэкап на яндекс диск. Правда там речь идет про сайт, но принципиальной разницы нет.
Заключение
Это все, что я хотел рассказать по поводу публикации файловых баз 1С в интернет. Постарался дать не только технические данные но и свои личные подробности, основанные на опыте подобных эксплуатаций. Я хоть и пытаюсь дистанцироваться от 1С, но она настолько популярна в России, что так или иначе сталкиваешься с этим продуктом. Да я и свою бухгалтерию ИП сам веду в 1С :)
Если захотите себе настроить что-то подобное, то обращайтесь ко мне. Я могу подобрать подходящее решение под ваш бюджет и выполнить настройку. Это будет дешевле быстрее и скорее всего лучше, чем вам настроят через франчайзи. По крайней мере то, что я видел, чаще всего было настроено так себе. Без акцента на безопасность и удобство, лишь бы работало.
Для каждого из видов подключения нужна своя аутентификация и отдельный набор ролей доступа. При одной публикации доступ пересекается, стандартные "грабли": при подключении телефонии тонкий клиент на автомате подключается под сервисным пользователем телефонии.
Разнесение на отдельные публикации
Так же остается проблема если нужна Basic аутентификация на уровне кода сервиса.
Вариант решения
Использовать обратный прокси перед основным web сервером и на его уровне настроить ограничения доступа.
Подготовка
- для тестов организовал DNS запись test.malikov.pro
- основная машина на win 10,
- сервер 1С на основной машине c apache 2.4 (IP 192.168.57.2) на порту 8080
- конфигурация УТ 11.4.11.100
- в качестве ОС использую Ubuntu,
- подключаюсь к ubuntu через SSH, (клиент), отправляю файлы через WinSCP(
Публикация клиента 1C
Проверяю корректность публикации
Настраиваю обратный прокси для /ut_demo_cl
По нормальному нужно в sites-available + добавить ссылку в sites-enabled, пока тестирую пишу напрямую в sites-enabled
Проверяю конфигурацию через SSH "nginx -t", перезагружаю конфигурацию "service nginx reload".
Реализовано через расширение, публикация с указанием сервисного пользователя (
Настраиваю обратный прокси для /api_vpbx
Перезагружаю конфигурацию, проверяю работоспособность
При обращении к сервису с basic аутентификацией идет перехват и замена пользователя по умолчанию на пользователя из запроса
Для обхода этой ситуации использую замену заголовка
Ограничение доступа по IP
Для телефонии известны IP адреса серверов (пример Манго-Офис,
Проверяю, получаю 403 ответ
Ограничение на количество запросов
Если API ресурсоёмкое, то имеет смысл поставить ограничение по количеству запросов с IP адреса
Добавляю в основную конфигурацию зону
Расширяю описание блока "/api_v1"
Проверяю, при частом запросе получаю 503.
Добавляю в настройки настройки для "/"
- Добавил репозиторий "sudo add-apt-repository ppa:certbot/certbot"
- Установил certbot "sudo apt install python-certbot-nginx"
- Запустил установку сертификата "sudo certbot --nginx -d test.malikov.pro"
- Для варианта настройки выбрал "2: Redirect"
В результате успешно получил сертификат. Проверяю работоспособность
Использование Web интерфейса для настройки
Если лезть и разбираться в конфигах и командах не очень хочется то можно поставить "Nginx Proxy Manager"
Запускается как докер контейнер
В базе на сколько понимаю работает в SQLite, можно подключить к Mysql.
Благодарю Алексея Лустина за информацию.
Применение в облачных средах
В kubernetes есть Ingress - механизм, обеспечивающий маршрутизацию входящего трафика на уровне приложения (L7), предоставляемый через Ingress-контроллер. В основе которого базово используется Nginx.
Благодарю за внимание.
Специальные предложения
Столько вопросов
Как сделать несколько подключений с разными правами через ВЕб
Вот оно ))
Кеширование через Nginx не пробовал?
(1) Статику кешировать относительно просто.
Хотел расширить по аутентификации, чтобы отсекало перед 1С и IPS приделать (Snort).
Пишите задачу, если получится, то дополню статью.
(3) При файловой базе больше проблема в блокировке файла чем в web сервере. Из моего опыта 3-5 пользователей работают нормально, далее уже сервер МИНИ и далее, видел информацию что запускали данный вариант на 10+ пользователей.
(4)
до двадцати есть вариант ?
или публикация на разных адресах
для пяти клиентов на адрес и четыре адреса ?
(5) Смотря какая конфигурация и сколько пользователей на 1 базу, сам бы в такое не стал лезть, потенциально куча проблем с администрированием. Публиковать можно на одном адресе на разных портах либо в разных корневых папках.
Добрый день!
Автор, объясни, пожалуйста, у меня не совсем пазл сошёлся в одном вопросе.
Ведь можно же было сделать просто разные (несколько) публикаций на IIS (Apache)?
Для чего тут ngnix?
Не докопаться ради, а ликбез для меня и таких как я.
Заранее спасибо за ответ!
(8) По простому: для меня проще настроить сертификаты letsencrypt на ubuntu c nginx, чем на win+IIS.
Если копнуть в web то обычно ставят прокси/балансировщик, а за ними уже сервера приложений, на уровень прокси можно навесить системы защиты, мониторинга. Удобно по настройке доступа, ограничения ставлю в одном месте.
На практике у меня на прокси приходит публичный траффик с одного IP и его распределяю исходя из доменных имен (из того что вижу у коллег раскидано на разные порты).
Из минусов, у меня нормально не запустился nextcloud+onlyoffice т.к. они в докере, в сборке перед ними свой прокси и между ними передается локальное имя, по хорошему нужно прокачать знание docker и по нормальному настроить.
Недавно в продолжение темы перевел вариант с docker и traefik.
Хорошая статья, спасибо!
Один только вопрос, можно ли вообще обойтись одним лишь nginx? Как можно опубликоваться в нём напрямую?
We have prepared pre-copmiled binaries for your. You need to download nginx.tar.gz and uncompress it:
- It creates an nginx directory for you. The config file is in nginx/conf/nginx.conf .
- We have provided a script named nginx in the directory. To run nginx , go to the nginx directory ( cd nginx ) and run ./nginx . .
Install nginx using apt-get :
Notes:
- The part of the nginx 's config file we need resides in /etc/nginx/sites-enabled/default .
- To edit the config file or run nginx , you need to use sudo .
Install homebrew , and then install nginx using brew :
Notes:
- nginx 's config file is in /usr/local/etc/nginx/nginx.conf .
- To edit the config file or run nginx , you need to use sudo : sudo nano /usr/local/etc/nginx/nginx.conf and sudo nginx .
Step 1 -- Booting Servers for Virtual Hosts
Write three different node applications running on different ports (say 8080, 8181, 8282) on your machine.
Step 2 -- Configure nginx's Port
To do so, you need to edit your nginx config file.
In the config file, find the server section:
If you're using CDF, make sure you change 80 to a vacant port number (ask for one from your instructor). If not, you can keep using 80 or change the port if you will.
Test nginx
- Run ./nginx on CDF, or run sudo nginx on your local machine.
- Open the browser and log on to localhost:$PORT (replace $PORT with the port number you configured for nginx ).
Step 3 -- Configure /
Let say we want to configure nginx to route requests for / , /blog , and /mail , respectively onto localhost:8080 , localhost:8181 , and localhost:8282 .
To route / , you need to edit your nginx config file.
In the config file, find the server section:
Now, change the location section to this snippet:
Step 4 -- Reload nginx's Configuration
To reload nginx 's configuration run: nginx -s reload on your machine.
Referesh your browser. Do you see the output from your node.js application? If yes, you are all set. If no, there is a problem with your config.
Step 5 -- Add /blog and /mail
To redirect /mail and /blog , you simply need to add new entries the location section in the config file:
Step 6 -- Reload Your nginx Configuration
Run nginx -s reload on your machine.
Log onto localhost:$PORT/blog in your browser. Do you see the output from your second node.js application?
Then log onto localhost:$PORT/mail . Do you see the output from your third node.js application?
If yes & yes, you are all set. If no, there is a problem with your config.
Step 7 -- Rewriting Requests
To fix this issue, we need rewrite the URL so that it matches the URL you can serve on your node.js applications.
To correctly rewrite URLs change your config file to match the following snippet:
Step 8 -- Reload and Test.
Step 9 (optional) -- Redirecting Based on Host Name
Note: Since you don't have access to a DNS server, you should add domain name entries to your /etc/hosts (you can't do this on CDF machines):
mohanss08 commented Aug 30, 2019 •
In my single server application runs with two different location below are them.
/etc/nginx/conf.d/application.conf file has the below code.
One application reverse proxy is working and other is not working. So how to run both applications in 80 port and with single IP address. Any assistance would be helpful.
NTMS2017 commented Oct 14, 2019
Part of my nginx conf.d as shown below. proxy_pass to internal networks working. Cant redirect to external site. I need to redirect this:
$host = my.website.com/admin to proxy_pass "https://admin.myothersite.com/httpsms";
adarshsrivastav commented Jan 16, 2020 •
I am facing one problem while trying to enable the proxy,
upstream my-app1 server 127.0.0.1:8085;
>
upstream my-app2 server 0.0.0.0:8084;
>
Command i used to start nginx docker - docker run -p 8080:80 -d nginxproxy1
I am seeing this error :
when i am trying to hit url from browser localhost:8080/hello, it throws above error!
when I hit 127.0.0.1:8080 it redirects to nginx, which is done correctly!
Читайте также: