• # seul ou en cluster ?

    Posté par  . Évalué à 4.

    en haut à droite :

    • create VM (pour une machine en KVM, tu peux y mettre ce que tu veux à partir de l'ISO d'un OS, windows, linux, BSD, OSX, etc)
    • create CT (pour creer un containeur LXC, forcement du linux puisque ca partage le noyau de la machine principale)

    viendront plus tard les problématiques de multireseau, de droit utilisateurs, etc

    • [^] # Re: seul ou en cluster ?

      Posté par  . Évalué à 1.

      Merci beaucoup.

      Comme je l'espérais proxmox me facilite la tâche de virtualisation.
      Donc vous m'avez tendu l'échelle, je monte, du moins je commence sans trop de vertige.

      En fait, comme je le comprends, il s'agit d'un proxmox seul. Sur un unique réseau local.
      L'objectif c'est d'installer des applications web, pas compatibles sur une même machine, exemple, Nextcloud et Collabora.

      J'ai le projet d'installer une instance diaspora et une Mastodon.
      Je suis perturbé par le mode d'installation qui place forcément le site dans /home/user. Aussi, je préfère une machine virtuelle par instnce. Plus facile aussi de gérer les certificats.

      Je rédige des comptes rendus de mes étapes avec proxmox, des tâches du projet (géré avec ganttproject) que je mettrai en ligne sur un blog.

      • [^] # Re: seul ou en cluster ?

        Posté par  . Évalué à 3.

        si tous tes projets sont compatibles linux/debian, tu peux faire un CT (Containeur LXC)
        c'est généralement plus léger en terme de ressource.

        pour démarrer cela, il faut aller sur le stockage disponible et afficher les templates
        par exemple :
        Local->Contents->Templates

        là tu choisis celui que tu veux "precharger" sur ton proxmox.

        Ensuite quand tu vas creer le CT, il va te demander à partir de quel template,
        tu choisis Local, il va lister un des templates préchargés, et t'installer ce containeur

        • [^] # Re: seul ou en cluster ?

          Posté par  . Évalué à 1.

          Encore merci.

          Effectivement la solution par conteneur LXC correspond bien à ce que je souhaite réaliser.
          En effet, toutes les applications tournent soit sous Ubuntu, soit sous Debian. Indéfectiblement linuxien depuis 1998.

          je suis en train de prendre connaissant de la liste de toutes les commandes LXC pour gérer les conteneurs (container. Bon j'ai un biais linguistique, utiliser les mots français mais je mets les équivalents anglais US pour qu'on s'y retrouve, la langue des technologies numériques, c'est l'anglais). Je me focalise sur l'utilisation des templates pour l'installation des environnements et des applications.

          • [^] # Re: seul ou en cluster ?

            Posté par  . Évalué à 2.

            les commandes LXC pour gérer les conteneurs

            installé proxmox pour utiliser la ligne de commande,
            autant installer juste le LXD (daemon LXc) et tout faire en ligne de commande ?

            bon j'avoue démarrer rapidement une machine à partir de l'interface web du proxmox
            et apprendre ensuite les commandes pour gérer depuis la ligne de commande, c'est plutot bien.

  • # La configuration réseau

    Posté par  . Évalué à 2.

    Ce qui peut poser problème quand on débute, c'est la configuration réseau.
    Combien de services accessibles ?
    IPv6 ou IPv4 ou les deux ?

    • [^] # Re: La configuration réseau

      Posté par  . Évalué à 1.

      J'ai les deux. Mais pour le moment, je privilégie IPv4.
      Je vais quand même paramétrer IPv6 au fur et à mesure.

      À la fin, j'aurai une demi-douzaine de services en ligne.
      Deux visio-conférences, big-blue-button et jitsi.
      Trois instances, mastodon, diaspora et j'espère peertube.
      Un Collabora associé à un nextcloud en prod.
      Un service de blogs.

      • [^] # Re: La configuration réseau

        Posté par  . Évalué à 1.

        Sur l'IPv4, comment tu t'y prends ?
        Tu achètes une ipv4 par service (mais ça devient compliqué)?
        Tu montes un reverse proxy mais dans ce cas, comment gères-tu le chiffrage de ta connexion ?
        Déchiffrage au reverse proxy et transfert en clair entre le proxy et le container de ton service ou utilisation du sni pour transférer chiffrer jusqu'au service ?

        • [^] # Re: La configuration réseau

          Posté par  . Évalué à 1.

          Je suis sur mon propre LAN avec une seule adresse IP fixe.
          Mon activité est non marchande.
          J'ai opté pour un reverse proxy (apache).
          Option 2, pour l'instant, déchiffrage au reverse proxy et transfert
          en clair vers le conteneur.
          Pour sni, j'ai commencé à regarder, j'ai encore besoin d'un peu de temps pour «avaler » ça.

          • [^] # Re: La configuration réseau

            Posté par  . Évalué à 3.

            Pour sni, j'ai commencé à regarder, j'ai encore besoin d'un peu de temps pour «avaler » ça.

            haproxy fait ca assez simplement, ci-dessous un exemple

            frontend monfront
  bind *:80
  bind *:443 ssl crt ....
# [...]

# definition des drapeaux pour selection du service final selon le SNI
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }

    acl drapeau_cloud req_ssl_sni -i cloud.domain.tld
    acl drapeau_service req_ssl_sni -i service.domain.tld

        use_backend moncloud if drapeau_cloud
        use_backend monservice if drapeau_service
  default_backend site_par_defaut

# et les services finaux
backend moncloud
  server 192.168.1.10:80 ...
# [...]
backend monservice
  server 192.168.1.20:80 ...
# [...]
backend site_par_defaut
  serveur 192.168.1.30:80 ...
# [...]

            • [^] # Re: La configuration réseau

              Posté par  . Évalué à 2.

              idem j'utilise HAProxy pour le reverse proxy.

              Par contre dans ta config, le backend devrait plutôt ressemblé à cela :

              backend moncloud
              mode tcp
              server 192.168.1.20:443

              • [^] # Re: La configuration réseau

                Posté par  . Évalué à 3. Dernière modification le 18 septembre 2020 à 20:37.

                pas dans le cas de la question où il dit faire le SSL sur le reverse proxy,
                et faire du non chiffré en interne (donc port 80)

                mais ta proposition pouvant l'intéressé, l'explication est la suivante :

                faire le frontend en mode TCP aussi,
                il va analyser le port 443 pour detecter le domaine demandé (le SNI)
                puis va passer le flux au backend port 443 qui va devoir gerer le chiffrement SSL

                avantage : gestion du certificat directement sur la machine finale (pratique pour letsencrypt par exemple, ou pour déplacer une machine avec les certificats qui vont avec)

                inconvenient : il faut plus de ressource sur la machine finale puisque c'est elle qui fait/defait le chiffrement

                • [^] # Re: La configuration réseau

                  Posté par  . Évalué à 2.

                  J'avais mal compris, je pensais que tu donnais un exemple avec déchiffrage dans le service final.

                  Dans ton exemple, quel est l'intérêt de matcher avec le sni ? vu que tu as déchiffré au niveau du proxy, tu as accès aux headers et donc au host.

                  • [^] # Re: La configuration réseau

                    Posté par  . Évalué à 3.

                    exact, je m'étais mélanger les pinceaux en copiant des bout de ma config

                    en fait c'était bien un mode TCP dans ma config

                    Frontend monfront
mode tcp
...

backend lebackendfinal
mode tcp
...

                    sinon en effet le SNI ne sert à rien puisqu'on a ouvert le SSL sur le haproxy, et donc on connait le header du domaine demandé.

                    le SNI ne sert que si on passe en TCP et que le SSL est géré sur la machine finale.

                    Merci de la correction.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.