Come impedire l'installazione del modulo Devel su ambienti di produzione


26

Utilizzando il nuovo Drupal 8 Configuration Manager, come posso impedirgli di installare il modulo Devel su determinati ambienti? Per quanto ne so, installarlo sul mio locale significa che la prossima volta che esporterò la configurazione e la sposterò negli altri miei ambienti (sviluppo, test, prod), verrà automaticamente abilitato.


L'utilizzo è drushaccettabile? L'ho scoperto l'altro giorno drush config-export --skip-modules=devel. Potrebbe esserci qualcosa di simile senza usare drush, ma non lo so.
mradcliffe,

Quindi dovrei farlo ogni volta che esporto la configurazione? Deve esserci un modo migliore: |
Cambraca,

Forse puoi aggiungere alcuni file di configurazione al tuo .gitignore.
digitaldonkey,


2
Penso che questa domanda sia troppo ampia a posteriori. Probabilmente ci sono molte buone risposte perché dipende da quale sia il processo di costruzione e sviluppo per il sito.
mradcliffe,

Risposte:


18

Metodo: Drush

  • Drush può ignorare gli stati di estensione abilitati durante la sincronizzazione della configurazione.

    drush cex --skip-modules=devel

    drush cim --skip-modules=devel

  • Con gli strumenti Drush CMI è possibile operare con un elenco di configurazioni da ignorare.

    drush cexy --ignore-list=/path/to/config-ignore.yml

    drush cimy --delete-list=/path/to/config-ignore.yml

Metodo: moduli

  • È possibile utilizzare il modulo Split configurazione che consente di:

    1. Dividi alcune configurazioni in una cartella dedicata
    2. Configurazione della lista nera
    3. Ignora un set di configurazione
    4. Configurato da entità di configurazione
  • Configurazione Modulo modalità sola lettura

    Questo modulo consente di bloccare eventuali modifiche alla configurazione effettuate tramite l'interfaccia utente dell'amministratore di Drupal. Ciò può essere utile in scenari in cui, ad esempio, le modifiche alla configurazione non devono essere eseguite nell'ambiente di produzione, ma solo in ambienti di gestione temporanea o locali.

    $settings['config_readonly'] = TRUE;

  • E un altro modulo è la configurazione dell'ambiente che consente di sovrascrivere la configurazione in base all'ambiente.


2
Non mi piace davvero avere tutte le dipendenze delle librerie per il modulo di sviluppo sui miei server di produzione, quindi lo aggiungo al compositore usando composer require --dev drupal/devel. Il vantaggio aggiuntivo è che l'installazione del compositore è più veloce, rendendo più rapida la distribuzione dei prodotti.
Duncanmoo,


6

Aggiornamento : la funzionalità descritta di seguito è stata rimossa di recente https://www.drupal.org/project/config_split/issues/2926505


Se si utilizza drush nel processo di distribuzione, è possibile effettuare le seguenti operazioni:

Crea un drushrc.phpfile nella stessa directory del tuo settings.php(ad esempio:) docroot/sites/defaulte inserisci quanto segue:

$drush_ignore_modules = array(
  'devel',
  'webprofiler',
  'devel_generate',
  'kint',
  'yaml_editor',
);

$command_specific['config-export']['skip-modules'] = $drush_ignore_modules;
$command_specific['config-import']['skip-modules'] = $drush_ignore_modules;

Questo significa che puoi manipolare i comandi drush cex/ drush cimper saltare i moduli, durante il loro processo.

Puoi leggere ulteriori informazioni sull'uso del filtro del modulo di configurazione in Drush 8 .


5

drush cex --skip-modulesè stato rimosso a favore di config_split come spiegato in questo numero, quindi le soluzioni qui basate su drush non hanno funzionato per me.

Ecco la soluzione basata sulla soluzione Duncanmoo che utilizza il modulo config_exclude

1. Installa config_exclude usando Composer richiede --dev e configuralo

$ composer require --dev drupal/config_exclude
$ drush en config_exclude -y
$ nano sites/default/setting.php

consenti settings.php da usare nel tuo ambiente di sviluppo locale

if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
  include $app_root . '/' . $site_path . '/settings.local.php';
}

Aggiungi le impostazioni di config_exclude nel file locale

$ nano sites/default/setting.local.php

ecco alcune impostazioni di esempio

$settings['config_exclude_modules'] = [
    'devel', 
    'config_exclude',
    'config_filter',
    ...
    'stage_file_proxy',
];

NOTA 1: config_filter è una dipendenza config_exclude quindi se non ti serve la produzione puoi escluderla sopra

NOTA 2: Il settings.local.phpnon è un requisito. Dipende se è controllato dal VCS o meno.

2. Il compositore richiede --dev

Quando si abilita un modulo che è puramente per lo sviluppo, utilizzare il flag --dev:

$ composer require --dev drupal/devel

Ciò comporta l'aggiunta di tali dipendenze nel file composer.json in request-dev:

...
    "require-dev": {
        "drupal/twig_xdebug": "^1.0",
        "drupal/devel": "^1.0@RC"
    }
}

Quindi se installi il sito SENZA i tuoi moduli di sviluppo usi:

$ composer install --no-dev

NOTA: nei tuoi ambienti di staging e prod, dovresti sempre fare --no-dev

3. utilizzare drush cex come si usa normalmente

$ drush cex 

non esporterà nessuna delle impostazioni dei moduli esclusi

NOTA: ho notato che le impostazioni di core.extension sembrano essere state modificate dopo aver eseguito il comando sopra, ma il corrispondente .yml non viene mai scritto sul disco rigido (anche dopo aver confermato will be deleted and replaced with the active config) quindi non c'è nulla da impegnare, immagino che dipenda dal interni del modulo config_exclude


Ho avuto un'esperienza molto simile a quella di @GiorgosK seguendo i suggerimenti precedenti. Questa soluzione ha funzionato perfettamente per me e contiene anche consigli ben ponderati. Ho anche notato i falsi negativi di core.extension, ma in realtà NON ha cambiato lo stato di git, quindi tutto va bene. Grazie
vrwired il

2

C'è un problema interessante per Drupal 8.3.x: consentire ai moduli di sviluppo di annullare la configurazione di esportazione . Il consenso generale è che la suddivisione della configurazione è attualmente la soluzione migliore.

Commento di swentel :

Volevo solo documentare brevemente come funziona config_split: l'entità config config config definisce ciò che è nella lista nera, permettendoti di inserire nella blacklist i moduli e / o gli oggetti di configurazione. L'esempio canonico, essendo in fase di sviluppo, ha già un caso d'uso interessante: viene fornito con system.menu.devel che, nel caso in cui si sviluppi una lista nera, il file di configurazione del menu non verrà rimosso poiché non vi è dipendenza. Anche se non è un grosso problema, la configurazione config ti consente di selezionare singolarmente anche quello, quindi viene rimosso sull'ambiente.

Commento di geerlingguy :

Ho provato alcuni metodi diversi per gestire la configurazione specifica per l'ambiente, e config_split sembra colpire la giusta usabilità contro un ulteriore sovraccarico finora. È semplice e leggero, ma mi consente di contrassegnare (e continuare a utilizzare) determinate configurazioni solo in determinati ambienti.


2

La suddivisione della configurazione potrebbe essere una soluzione praticabile per alcuni.

La gestione della configurazione di Drupal 8 funziona al meglio durante l'importazione e l'esportazione dell'intero set della configurazione dei siti. Tuttavia, a volte agli sviluppatori piace rinunciare alla solidità di CM e avere un super-set di configurazione attivo sulla propria macchina di sviluppo e distribuire solo un sottoinsieme. L'esempio canonico per questo è avere il modulo di sviluppo abilitato o avere alcuni posizionamenti di blocchi o viste nell'ambiente di sviluppo e quindi non esportarli nel set di configurazione da distribuire, pur essendo in grado di condividere la configurazione di sviluppo con i colleghi.

https://www.drupal.org/project/config_split


+1 per la suddivisione della configurazione, lo uso sempre per avere Develop e altri moduli come l'interfaccia utente di campo e l'interfaccia utente di Views disabilitati in prod. Vedi Disabilitare i moduli usando la divisione di configurazione .
leymannx,

2

C'è un modo accurato per farlo, in cui finisci con i tuoi moduli dev impegnati in compositore per comodità e la configurazione di quei moduli non viene aggiunta alla tua esportazione di configurazione (ci sono 2 parti):

1. Il compositore richiede --dev Quando si abilita un modulo che è puramente per lo sviluppo, utilizzare il flag --dev:

$ composer require --dev drupal/devel

Ciò comporta l'aggiunta di tali dipendenze nel file composer.json in request-dev:

...
    "require-dev": {
        "drupal/twig_xdebug": "^1.0",
        "drupal/devel": "^1.0@RC"
    }
}

Quindi se installi il sito SENZA i tuoi moduli di sviluppo dici:

$ composer install --no-dev

NB: Nei tuoi ambienti di staging e prod, dovresti sempre fare --no-dev

2. Utilizzare il modulo config_split

Il modulo di suddivisione della configurazione consente di creare raggruppamenti di esportazione della configurazione che possono essere abilitati o disabilitati in un ambiente.

In realtà ho 3 divisioni:

  1. Configurazione del sito principale (abilitata ovunque; sviluppo, stadiazione e produzione)
  2. Configurazione della gestione temporanea (abilitata in sviluppo e gestione temporanea): include il modulo di reinstradamento della posta elettronica
  3. Dev config - include devel, kint ... ma non reindirizzare la posta elettronica poiché viene fornito con la configurazione della gestione temporanea abilitata in dev.

1
Non dovresti davvero usare le dipendenze degli sviluppatori in questo modo. Sono più per strumenti, come lo sniffer di codice, che non avresti bisogno di eseguire in produzione. Se sono abilitati e Drupal si aspetta l'installazione del modulo e il codice non è presente, ciò potrebbe portare all'instabilità del sito. Drupal / Composer potrebbe comunque tentare di caricare un file che non si trova sul file system se è una dipendenza dev.
Frank Robert Anderson,

@FrankRobertAnderson non proponi una soluzione migliore? Non voglio un modulo di sviluppo o librerie dipendenti sul mio server di produzione, cosa proponi?
Duncanmoo,

Drupal non offre davvero una buona opzione per questo. Il tuo piano non è orribile, ma porterà a problemi se non stai attento. Il problema che ho con il tuo piano è che config_split diventa il perno su cui si basa tutto il tuo sito. Voterei il tuo voto se non fosse per la cosa della dipendenza da sviluppo, che non era nemmeno una domanda nel PO.
Frank Robert Anderson,

1

Ho realizzato una piccola sceneggiatura per fare tutto in un colpo solo.

#!/bin/bash

drush pm-uninstall devel -y
drush pm-uninstall field_ui -y
drush pm-uninstall field_name_prefix_remove -y

drush config-export

drush en devel -y
drush en field_ui -y
drush en field_name_prefix_remove -y

1

Puoi anche vedere il modulo Config Ignore .

Questo modulo è uno strumento che ti consente di mantenere la configurazione desiderata, in atto.

Supponiamo che tu voglia che la configurazione di system.site (che contiene il nome, lo slogan, l'e-mail, ecc.) Del sito rimanga intatta, sul tuo sito live, indipendentemente dalla configurazione, nella cartella di esportazione.

O forse ti stai stancando di cambiare le impostazioni devel.sett ogni volta che importi la configurazione?


Il modulo Config Ignore non è adatto in questo caso. Dalla pagina del modulo: non ignorare la configurazione core.extension poiché ti impedirà di abilitare i nuovi moduli con un'importazione di configurazione. Utilizzare il modulo Config Split per moduli specifici dell'ambiente.
bmunslow,

1

A tale scopo è possibile utilizzare un modulo di override di distribuzione. Leggi il seguente link per una descrizione dettagliata:

http://dcycleproject.org/blog/46/continuous-deployment-drupal-style

Tuttavia , il modo migliore per farlo sarebbe disabilitare il modulo in locale e quindi esportare la configurazione.

Drupal fornisce un modo per sovrascrivere le impostazioni di configurazione settings.php , ma non sono valide per disabilitare / abilitare i moduli.

Da default.settings.php:

/**
 * Configuration overrides.
 *  * To globally override specific configuration values for this site,
 * set them here. 
 * 
 *
 * blah..blah...blah
 *
 *  
 * There are particular configuration values that are risky to override. For
 * example, overriding the list of installed modules in 'core.extension' is not
 * supported as module install or uninstall has not occurred. Other examples
 * include field storage configuration, because it has effects on database
 * structure, and 'core.menu.static_menu_link_overrides' since this is cached in
 * a way that is not config override aware. Also, note that changing
 * configuration values in settings.php will not fire any of the configuration
 * change events.
 */
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.