Après plusieurs années d'utilisation de 1C dans la virtualisation de conteneurs Proxmox, il y avait suffisamment de cônes emballés, que je décrirai ici comme de brèves notes générales sur les étapes du processus de mise en œuvre.
Ce n'est pas un guide d'action ou un manuel. Si l'un des éléments doit être décrit plus en détail - n'hésitez pas dans les commentaires.
Planification et évaluation des risques
Lorsque vous avez peint les sommes d'économies, de stabilité, d'évolutivité et d'autres goodies avec des yeux brûlants, ne vous oubliez pas. Le minimum est un bon matériel, une conduite normale, des lecteurs rapides, une version x64 du serveur 1C. Il est toujours conseillé de demander une sorte de formation sur le sujet. Pour que la direction comprenne qu’elle investit dans sa propre infrastructure et son propre personnel, et non pas simplement économiser une somme ronde à l’improviste.
Achat de logiciel. Intégrateur
Il est conseillé de choisir quelqu'un qui a au moins une certaine expérience de la prise en charge des versions linux de 1C. Prenez le temps d'appeler et de demander. En conséquence, personne ne vous aidera de toute façon et vous serez confronté à tous les problèmes, mais au moins sans les conseils stupides et ennuyeux sur rdp et mssql.
Configuration de l'hĂ´te
Lorsque vous travaillez avec proxmox, c'est un péché de ne pas utiliser le merveilleux mécanisme lxc.mount pour monter des répertoires de l'hôte vers des conteneurs (en plus, en préservant acl). Pour empêcher les conteneurs de gonfler à cause des journaux et des sauvegardes, vous devez créer à l'avance des sections et des répertoires à ces fins sur l'hôte, ainsi que des tâches périodiques pour la rotation et le nettoyage. Vous dirigerez donc les sauvegardes et les journaux à un seul endroit, et vous verrez que c'est bien.
Choix de la configuration du serveur d'applications et du serveur de base de données
Vous êtes certainement déjà familier avec l'approche classique du gourou 1c, en plaçant la base de données sur le même serveur que le serveur d'applications. C'est maintenant une grande chance de ne pas le faire. Le fait est que si vous mesurez la vitesse du transfert de données "réseau" entre conteneurs, vous obtiendrez au moins 25-30 Gbit / s. N'hésitez pas à conduire la base de données depuis la plage et vous obtiendrez un serveur d'applications monolithique léger et plusieurs serveurs de bases de données faciles à profiler, à sauvegarder et à entretenir.
Configuration du serveur de base de données
PostgreSQL de 1C ou Postgres Professional fonctionne très bien dans des conteneurs prêts à l'emploi.
Pour des raisons de commodité uniquement, je créerais d'abord un modèle de conteneur vide avec un serveur de base de données, puis je le clonerais sous chaque infobase connectée au serveur d'applications. Dans ce modèle, vous devez immédiatement monter le journal et les répertoires de sauvegarde à partir de l'hôte et, en conséquence, y rediriger les journaux les plus épais. Il est également judicieux d'effectuer immédiatement des tâches de sauvegarde, par exemple via le mécanisme pg_dump all dans ces répertoires. Lors de la génération des fichiers de sortie, utilisez $ hostname. Vous obtenez donc un set de gentleman pour toute occasion
Configuration du serveur d'applications
Tout va sans fonctionnalités, routine et ennuyeux, seulement si vous n'installez pas x86-server sur x64 OS. Mais même alors, tout peut être décidé. Par exemple, si vous installez x86 1C sur Centos7, il existe un excellent référentiel avec des packages x86
mirror.centos.org/altarch/7/os/i386/PackagesÀ partir de là , vous aurez certainement besoin de: ImageMagick-c ++ - devel, fontconfig, libgsf, http, httpd-devel, ainsi que libpng et libpng-devel pour imprimer les codes-barres
Licence
Beaucoup sont contre les licences logicielles et préconisent un HASP plus cher mais fiable. C'est comme le ski et le snowboard. Vous décidez quoi casser - la clavicule ou la cheville. Il y a des problèmes à la fois de transfert de hasp vers le conteneur et d'obtention correcte de licences logicielles.
Si vous décidez de prendre des licences logicielles, soyez prudent avec les cœurs de processeur. Comme indiqué dans la documentation, vous pouvez augmenter (mais pas réduire) le nombre de cœurs et de processeurs sans nouvelle licence. Cependant, Proxmox, lors de la modification du nombre de cœurs de processeur disponibles dans le conteneur, modifie le CoreID du premier cœur. Autrement dit, si pour commencer, vous avez créé un conteneur avec 1 cœur et attaché à CoreID 0 lors de la licence, vous serez surpris en augmentant le nombre de cœurs à 4, la numérotation CoreID ne sera pas 0,1,2,3 mais 1,2,2,4 . En conséquence, les licences s'envoleront
Si cela arrivait - ne désespérez pas. Les licences peuvent être facilement réactivées à l'aide des codes joints. Et vous pouvez mettre dans la configuration du conteneur un cœur de plus que le montant réel. Par exemple, 9 pour un serveur à huit cœurs. Ensuite, CoreID 0 reviendra et ne vous quittera pas.
J'espère que ces notes aident quelqu'un