Exécution de Lagom en production

Question

Je travaille sur la mise en place d'une application Lagom en production. J'ai essayé de contacter Lightbend pour la licence ConductR mais je n'ai pas entendu depuis longtemps. Donc, maintenant je cherche une approche alternative. J'ai plusieurs questions.

Comme l'échelle de l'application est assez petite en ce moment, je pense que l'utilisation d'un localisateur de service statique fonctionne pour moi en ce moment (ouvert à d'autres alternatives). En outre, j'utilise MySQL comme magasin d'événements au lieu de la configuration par défaut de Cassandra (Raisons non pertinentes pour ce thread).

Pour supprimer Cassandra et service de Lagom Locator, j'ai ajouté les lignes suivantes à mon build.sbt:

lagomCassandraEnabled in ThisBuild := false 

J'ai également ajouté la pièce suivante à mon application.conf avec le module service1-impl.

lagom.services { 
    service1 = "http://0.0.0.0:8080" 
} 

Pour l'environnement dev, j'ai été en mesure d'exécuter avec succès mon application à l'aide sbt runAll dans une session tmux. Avec cette configuration, il n'y a pas de localisateur de service fonctionnant sur le port 8000 par défaut, mais je peux frapper individuellement le service1 sur le port 8080. (Je ne sais pas si c'est le comportement attendu.)

J'ai exécuté sbt dist pour créer un fichier zip, puis l'ai décompressé et j'ai exécuté l'exécutable. Fait intéressant, le fichier zip a été créé dans le dossier service1-impl. Donc, si j'ai plusieurs modules (services?), Sbt dist va-t-il créer des fichiers zip individuels pour chacun des services?

Lorsque j'exécute l'exécutable créé via sbt dist, il tente de se connecter à Cassandra et lance également un localisateur de service et ignore la configuration du localisateur de service statique que j'ai ajouté. Fondamentalement, il semble qu'il ignore les lignes que j'ai ajoutées à build.sbt. Quelqu'un peut-il expliquer cela? Enfin, si je devais avoir 2 services, service1 et service2, et 2 nœuds dans le cluster avec le nœud 1 exécutant service1 et le nœud 2 exécutant les deux services, à quoi ressemblerait mon localisateur de service statique dans le fichier application.conf et puisque chaque service aurait son propre application.conf, devrais-je copier la même configuration localisateur de service statique dans tous les application.confs?

Est-ce que ce serait quelque chose comme ça?

lagom.services { 
    service1 = "http://0.0.0.0:8080" 
    service1 = "http://1.2.3.4:8080" 
    service2 = "http://1.2.3.4:8081" 
} 

Comme chaque acteur spécifique serait donné naissance à l'un des nœuds, comment serait-il travailler avec cette configuration de localisation de service?

De même, je ne veux pas exécuter cela dans une session tmux en production. Quel serait le meilleur moyen de finalement exécuter ce code en production?

Answer 1

Vous pouvez commencer immédiatement avec ConductR en mode dev, gratuitement, sans contacter les ventes. Les instructions sont à: https://www.lightbend.com/product/conductr/developer Vous devez vous inscrire (lire: fournir un courriel valide) et accepter TnC pour accéder à cette page. Le sandbox est libre d'utiliser pour le mode dev aujourd'hui, vous pouvez donc voir si ConductR est bon pour vous rapidement et facilement. Pour la production, je suis ravi de vous annoncer que vous pourrez bientôt déployer jusqu'à 3 nœuds en production si vous enregistrez w/Lightbend.com (comme ci-dessus) et générer une clé de licence 'tierce partie' .

Lagom est influencé par les microservices. Il y a toujours Akka et Play si ces opinions ne sont pas partagées par un projet.Une partie de cette opinion est que le déploiement devrait être facile. Les bons outils se sentent «bien» dans la main. Vous êtes bien sûr libre de déployer l'application comme vous le souhaitez, mais soyez prêt à produire plus de polyfill plus loin des sentiers balisés.

En ce qui concerne la recherche de service, ConductR fournit la redirection pour les recherches de service HTTP pour une utilisation avec 'withFollowRedirects' sur Play WS [1] En ce qui concerne sbt dist, chaque service sous-projet sera un paquet. Vous pouvez le voir dans l'exemple Chirper [2] sur lequel sbt dist génère chirp-impl.zip, friend-impl.zip, activity-stream-impl, etc. comme vu dans le chirper top niveau build.sbt fichier. Comme ConductR est le chemin propre et éclairé, vous pouvez référencer comment il fait les choses afin de mieux comprendre comment remplacer le poly de déploiement de Lagom avec le vôtre. C'est l'interface que Lagom connaît le mieux. Beaucoup de ConductR excepté le noyau est déjà OSS donc peut essayer github si les docs ne couvrent pas quelque chose.

Divulgation: Je suis un Lightbender ConductR-ing.

1. http://conductr.lightbend.com/docs/1.1.x/ResolvingServices

2. git@github.com: lagom/activateur-lagom-java-chirper.git