środowiska specyficzne właściwości w JBoss AS7

Question

mamy 4 serwerów uruchamianych JBoss AS7:

• dev
• Test
• acc
• prod

Na każdym JBoss, proste webapp będzie działać. Ta aplikacja używa sprężyny i wymaga ustawienia niektórych właściwości:

webservice.endpoint=interface.url.com 
webservice.port=7676 

Właściwości będą się różnić w zależności od środowiska. Sposób w jaki sobie z tym poradzimy w tej chwili jest następujący:

Mam plik JAR z pojedynczym plikiem, config.properties. Ten plik właściwości zawiera wszystkie moje właściwości. Włączam ten słoik do globalnego modułu jboss i konfiguruję go w moim domain.xml (lub standalone.xml), który ma być dołączony. Działa to, ponieważ wiosną można uzyskać dostęp do właściwości podczas wytwarzania fasoli.

Jednak wydaje się zbyt skomplikowane, aby przekształcić właściwości w słoik, w moduł. Myślałem, że powinienem użyć właściwości systemu, aby to osiągnąć? Moje pytanie brzmi: czy jest to dobre miejsce na umieszczenie wszystkich właściwości specyficznych dla środowiska, specyficznych dla aplikacji? Zostaną one załadowane do maszyny JVM, aby każdy mógł uzyskać do nich dostęp w dowolnej chwili (zwłaszcza Spring, która korzysta z notacji ${myProperty}, aby uzyskać dostęp do właściwości). Dodatkowo, kiedy dodaję właściwości za pomocą konsoli w mojej przeglądarce, czy są one przechowywane? Nie widzę ich w domain.xml ani host.xml.

Answer 1

jeśli używasz rozwiązania JAR: - użyj unikalnego klasyfikatora dla każdego środowiska. Będziesz miał x plików właściwości: dev_config.properties/test_config.properties, itd ...

w ten sposób możesz ustawić unikalny JAVA_OPTS, który ustawia środowisko, w którym jesteś. wtedy masz prawo pliku properties:

używając: System.getenv("ENV") lub System.getProperty("ENV")

if ("DEV".Equals(System.getenv("ENV")) 
    here you load ==> the dev_config.properties 

załadować właściwości do słoika To jest naprawdę łatwe z tej wtyczki maven.

<plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-assembly-plugin</artifactId> 
      <executions> 
       <execution> 
         <id>packaging-deployment_manifests_bundle</id> 
         <phase>package</phase> 
         <goals> 
          <goal>attached</goal> 
         </goals> 
         <configuration> 
          <descriptors> 
         <descriptor>descriptors/deployment_manifests_bundle.xml</descriptor> 
          </descriptors> 
         </configuration> 
        </execution> 
       </executions> 
      </plugin> 

jeśli pójdziesz z environment_variables: Nigdy nie próbowałem tego rozwiązania w moich projektach, zawsze szedł z rozwiązaniem plik właściwości. ale jeśli masz tylko kilka zmiennych aby ustawić, to może być jeszcze szybciej ... można uzyskać dostęp do tych zmiennych z:

import java.util.Map; 

public class EnvMap { 
    public static void main (String[] args) { 
     Map<String, String> env = System.getenv(); 
     for (String envName : env.keySet()) { 
      System.out.format("%s=%s%n", 
           envName, 
           env.get(envName)); 
     } 
    } 
} 

Dodawanie danych w zmiennych środowiskach może być OK, jeśli to nic wrażliwe, takie jak hasła i lubi. Łatwiej jest IMO zaciemnić dane w pliku właściwości. Więc jeśli chodzi o bezpieczeństwo, należy to rozważyć.

Answer 2

W mojej firmie używamy do przechowywania właściwości zależnych od środowiska w bazie danych. Oznacza to, że masz bazę danych dla każdego środowiska. Nie wiesz, czy twoja aplikacja ma bazę danych do ich przechowywania.

Innym rozwiązaniem byłoby wykorzystanie właściwości systemu, które określają albo inaczej na każdym serwerze lub zmiany w czasie wykonywania podczas uruchomienia serwera:

• określić w swojej standalone.xml, z default, które będą stosowane, jeżeli nie my.cmd-line-descriptor podano

  <system-properties> 
      <property name="my-specific-value" value="${my.cmd-line-descriptor:default}"/> 
      ... 
  </system-properties> 
  

• razie potrzeby wymienić na starcie appserver:

  java ... -Dmy.cmd-line-descriptor=another-value 
  

Dla ciebie dodatkowe pytanie, proponuję spojrzeć na zmianach dokonanych z konsoli w tmp/vfs katalogów swoich appservers

Answer 3

Jeśli używasz Maven w projekcie można ustawić te właściwości przez środowisko, w różne profile:

<profiles> 
    <profile> 
     <id>dev</id> 
     <properties> 
     <webservice.endpoint>interface.url.com</webservice.endpoint> 
     <webservice.port>7676</webservice.port> 
     </properties> 
    </profile> 
    <profile> 
     <id>test</id> 
     <properties> 
     <webservice.endpoint>test url</webservice.endpoint> 
     <webservice.port>whatever port</webservice.port> 
     </properties> 
    </profile> 
</profiles> 

Następnie podczas kompilowania projektu trzeba określić środowisko jesteś kompilacją w parametr -P wykorzystać właściwości tego profilu:

maven clean install -P dev 

Następnie możesz uzyskać dostęp do tych właściwości za pomocą sprężyny.

Answer 4

nie widzę ich w domain.xml lub host.xml

Są tam prawo na najwyższym poziomie w <server> na autonomiczny lub <domain> dla domeny jak tego

<server xmlns="urn:jboss:domain:1.7"> 
... 
    <system-properties> 
     <property name="myapp.env" value="dev"/> 
    </system-properties> 
... 
</server> 

następnie wiosną może go zobaczyć jako ${myapp.env} lub dowolny inny kod jako właściwości systemu.

Mogą być ustawione z JBoss Admin Console, a także w zakładce „Konfiguracja” na samym dole jest „Właściwości systemu” - to jest rzeczywiście treść tego <system-properties> tag w domain.xml

Ponadto można je stosować wewnątrz domeny domain.xml. Jako przykład, jeśli masz pliki myapp.properties w różnych katalogach opartych na środowisku można to zrobić jak:

<server xmlns="urn:jboss:domain:1.7"> 
... 
<system-properties> 
    <property name="myapp.env" value="dev"/> 
    <property name="myapp.config.file" value="${myapp.env}/myapp.properties"/> 
</system-properties> 
... 

Więc ścieżka do pliku zostanie dev/myapp.properties i wiosna będzie go zobaczyć jako $ {MojaApl .config.file}, a następnie można załadować właściwości stamtąd.

PS. Pamiętam też, że określone właściwości systemu można ustawić w definicji modułu lub nawet w deskryptorze wdrażania aplikacji jboss-deployment-structure.xml - nie jestem pewien co do ostatniego ... BTW nie jest tak w przypadku twojego pytania o różnicowanie według środowiska.

PPS. Informacje o przechowywaniu .properties w systemie plików - Zachowaj je w pliku JAR to zły pomysł. wymaga przebudowania i wdrożenia za każdym razem, gdy zmieni się jakaś własność.

Pliki .properties są po to, aby tego uniknąć.Więc muszą być poza rozmieszczeniem.

Zależy więc od polityki sieci organizacji.

Raz na jakiś czas było to katalog NFS z różnymi nazwami plików, takich jak dev_myapp.properties, test_myapp.properties itp

Innym razem był to jeden z podkatalogów katalogu NFS - dev, badania itp o tej samej nazwie pliku w każdym.

W mojej obecnej organizacji NFS nie jest dozwolone. Każda instancja Slave w klastrze ma własny klon pliku w tej samej lokalizacji, to jest config/myapp.properties. dlatego istnieje tylko jedna właściwość systemowa zdefiniowana jako ścieżka do tego pliku. Każde środowisko ma swoją własną wersję pliku.

powodzenia!