Решение
Всегда убедитесь, что вы резервируете свои IP-адреса при использовании Stati c IP
Версии
VirtualBox Version: 6.0.0 ( I think )
Vagrant Version: 2.2.3
CentosBox: "centos/7"
Nginx Version: 1.16.1
uWSGI Version: 2.0.18
Django Version: 2.2.1
Фон
У меня есть работает две бродячих коробки, тест и производство. Разница только в IP и количестве ядер. Я настроил оба, чтобы я мог s sh прямо в боксы, вместо того, чтобы s sh войти в хост-компьютер, а затем запустить 'vagrant s sh'
General Issue
Производственная версия случайным образом загрузит меня из s sh (сброс соединения по IP-порту 22), а затем я получу отказ в соединении. Если я введу sh на хост-компьютер и затем 'vagrant s sh', я все равно смогу войти, и все будет в порядке, я даже смогу пропинговать другие компьютеры в сети. Но я не могу получить к нему доступ со стороны хоста, это относится и к серверу nginx (IP-адрес отказался подключаться) на chrome
Эта проблема иногда решается через пару минут, но в большинстве случаев требуется «vagrant destroy» и «vagrant up --provision» / воссоздать коробку. Я также иногда получаю загрузку с хост-машины, а также с тестового окна, но к обоим я могу получить внешний доступ после того, как (даже на тестируемом сервере nginx) я работаю через VPN и иногда получаю загрузку из это также, но я могу восстановить, когда я замечаю
VagrantFile
# -*- mode: ruby -*-
# vi: set ft=ruby :
# Please don't change it unless you know what you're doing.
Vagrant.configure("2") do |config|
config.vm.box = "centos/7"
config.vm.hostname = "DjangoProduction"
# Disable automatic box update checking. If you disable this, then
# boxes will only be checked for updates when the user runs
# `vagrant box outdated`. This is not recommended.
# config.vm.box_check_update = false
# Create a public network, which generally matched to bridged network.
# Bridged networks make the machine appear as another physical device on
# your network.
config.vm.network "public_network", ip: "IP"
# Share an additional folder to the guest VM. The first argument is
# the path on the host to the actual folder. The second argument is
# the path on the guest to mount the folder. And the optional third
# argument is a set of non-required options.
config.vm.synced_folder "./", "D:/abcd", type: "sshfs", group:'vagrant', owner:'vagrant'
# Provider-specific configuration so you can fine-tune various
# backing providers for Vagrant. These expose provider-specific options.
# Example for VirtualBox:
#
config.vm.provider "virtualbox" do |v|
v.name = "DjangoProduction"
# test has these two commented out
v.memory = 6000
v.cpus = 4
end
#
# View the documentation for the provider you are using for more
# information on available options.
## Keys
### For SSH directly into the Box
# Work Laptop Key
config.vm.provision "file", source: ".provision/keys/work.pub", destination: "~/.ssh/work.pub"
config.vm.provision "shell", inline: "cat ~vagrant/.ssh/work.pub >> ~vagrant/.ssh/authorized_keys"
# Personal Laptop Key
config.vm.provision "file", source: ".provision/keys/msi.pub", destination: "~/.ssh/msi.pub"
config.vm.provision "shell", inline: "cat ~vagrant/.ssh/msi.pub >> ~vagrant/.ssh/authorized_keys"
##
required_plugins = %w( vagrant-sshfs )
required_plugins.each do |plugin|
exec "vagrant plugin install #{plugin};vagrant #{ARGV.join(" ")}" unless Vagrant.has_plugin? plugin || ARGV[0] == 'plugin'
end
# Enable provisioning with a shell script. Additional provisioners such as
# Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the
# documentation for more information about their specific syntax and use.
config.vm.provision :shell, path: ".provision/boot.sh"
end
boot. sh
# networking
sudo yum -y install net-tools
ifconfig eth1 IP netmask 255.255.252.0
route add -net 10.1.0.0 netmask 255.255.252.0 dev eth1
route add default gw 10.1.0.1
# I manually set the gateway so It can be accessed through VPN
## install, reqs + drop things to places - gonna leave all that out
Сообщения об ошибках
Django
Эта проблема начала появляться в начале этой недели с django, посылая мне сообщения об ошибках с сообщением. это всегда случайные URL, нет никакой согласованности
OperationalError at /
(2003, 'Can\'t connect to MySQL server on \'external-ip\' (110 "Connection timed out")')
Раньше я получал это письмо один раз в день и не обращал на него внимания, но в настоящее время он отправляет мне не менее 20 сообщений в день, а сайт почти непригоден для использования - это либо очень медленно, либо я получаю chrome ошибок: 'ERR_CONNECTION_TIMED_OUT' или 'ERR_CONNECTION_REFUSED' или 'ERR_CONNECTION_RESET' .. все будет хорошо в течение часа, а потом все будет в порядке
Я изначально думал, что это проблема с БД или uwsgi или django, но вчера работая с ним, я понял, что существует корреляция с тайм-аутом и выходом из s sh.
Nginx Настройки сервера (я не изменился nginx .conf)
upstream django {
server unix:///vagrant/abcd.sock;
}
server{
listen 8080;
return 301 https://$host$request_uri;
}
server{
charset utf-8;
listen 443 ssl;
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
location / {
uwsgi_pass django;
include /vagrant/project/uwsgi_params;
uwsgi_read_timeout 3600;
uwsgi_ignore_client_abort on;
}
location /static {
alias /vagrant/static;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /vagrant/templates/core;
}
}
Используемая команда UWSGI
uwsgi --socket abcd.sock --module project.wsgi --chmod-socket=664 --master --processes 8 --threads 4 --buffer-size=65535 --lazy
Nginx Журналы ошибок
Ничего.
Файл сообщений
показывает дамп '(110 "Тайм-аут соединения") ", когда это происходит