Puncte:3

Migrarea conținutului din mediul live în mediul de dezvoltare cu Docker

drapel id

Încerc să creez un server de dezvoltare localhost cu un mediu Drupal 8 dockerizat și trebuie să transfer conținutul de pe site-ul live pe localhost.

Am urmat instrucțiunile pentru dockerizare aici: https://www.drupal.org/docs/develop/local-server-setup/docker-with-solr-integration/docker-configuration

Și acum trebuie să migrez conținutul de pe site-ul live în serverul de dezvoltare și sunt confuz cu privire la proces.

Orice informatie ar fi foarte apreciata!

Editați | ×:

O modalitate de a importa în mediul meu local a fost să creez un Dump SQL din baza de date live și apoi încărcați-o în fișierul meu docker-compose.

versiunea: '3'
Servicii:
  db:
    imagine: mariadb:10.3
    mediu inconjurator:
      MYSQL_DATABASE: drupal
      MYSQL_ROOT_PASSWORD: MyGreatPassword
    volume:
      - db_data:/var/lib/mysql
    reporniți: întotdeauna

  phpmyadmin:
    depinde de:
      - db
    imagine: phpmyadmin/phpmyadmin
    reporniți: întotdeauna
    porturi:
      - „8080:80”
    mediu inconjurator:
      PMA_HOST: db
      MYSQL_ROOT_PASSWORD: MyGreatPassword
      UPLOAD_LIMIT: „500 M”

  drupal:
    depinde de:
      - db
    construi: .
    porturi:
      - „2345:80”
      - „2443:443”
    volume:
      - ./:/var/www/html
    reporniți: întotdeauna

  solr:
    imagine: solr:8
    porturi:
      - „8983:8983”
    volume:
      - ./mycores/collection1:/mycores/collection1
    punct de intrare:
      - docker-entrypoint.sh
      - solr-precreate
      - colectia 1
      - /mycores/collection1
volume:
  db_data:

Acum, am această eroare.

În linia 59 Statement.php                                                                              
  SQLSTATE[42S22]: Coloana nu a fost găsită: 1054 Coloana necunoscută „etichete” în „lista de câmpuri”

În linia Connection.php 701:
                                                                                                                                             
  SQLSTATE[42S22]: Coloana nu a fost găsită: 1054 Coloana necunoscută „etichete” în „lista de câmpuri”: INSERT INTO {cache_bootstrap} (cid, expire, created, tags,  
   sumă de control, date, serializate) VALORI (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_2  
  _3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6) LA ACTUALIZAREA CHEIEI DUPLICATE cid = VALUES(cid), expire = VAL  
  UES(expira), creat = VALUES(creat), tags = VALUES(etichete), checksum = VALUES(checksum), data = VALUES(date), serialized = VALUES(serial  
  izat); Matrice                                                                                                                               
  (                                                                                                                                          
      [:db_insert_placeholder_0] => hook_info                                                                                                
      [:db_insert_placeholder_1] => -1                                                                                                       
      [:db_insert_placeholder_2] => 1626559961.843                                                                                           
      [:db_insert_placeholder_3] =>                                                                                                          
      [:db_insert_placeholder_4] => 0                                                                                                        
      [:db_insert_placeholder_5] => a:39:{s:10:"token_info";a:1:{s:5:"group";s:6:"tokens";}s:16:"token_info_alter";a :1:{s:5:"grup";s:6:"la  
  kens";}s:6:"tokens";a:1:{s:5:"grup";s:6:"tokens";}s:12:"tokens_alter";a:1:{s:5 :"grup";s:6:"tokens";}s:10:"views_data";a:1:{s:5:"grup";  
  s:5:"views";}s:16:"views_data_alter";a:1:{s:5:"grup";s:5:"views";}s:13:"views_analyze";a:1 :{s:5:"grup";s:5:"views";}s:22:"views_invalid  
  ate_cache";a:1:{s:5:"grup";s:5:"vizualizări";}s:26:"views_plugins_access_alter";a:1:{s:5:"grup";s:5: "views";}s:24:"views_plugins_area_alter";  
  a:1:{s:5:"group";s:5:"views";}s:28:"views_plugins_argument_alter";a:1:{s:5:"group";s:5:"views" ;}s:36:"views_plugins_argument_default_alte  
  r";a:1:{s:5:"grup";s:5:"vizualizări";}s:38:"views_plugins_argument_validator_alter";a:1:{s:5:"grup";s:5: "views";}s:25:"views_plugins_cache_al  
  ter";a:1:{s:5:"grup";s:5:"vizualizări";}s:36:"views_plugins_display_extender_alter";a:1:{s:5:"grup";s:5: "views";}s:27:"views_plugins_display_  
  alter";a:1:{s:5:"grup";s:5:"vizualizări";}s:32:"views_plugins_exposed_form_alter";a:1:{s:5:"grup";s:5: "views";}s:25:"views_plugins_field_alte  
  r";a:1:{s:5:"grup";s:5:"vizualizări";}s:26:"views_plugins_filter_alter";a:1:{s:5:"grup";s:5: "views";}s:24:"views_plugins_join_alter";a:1:{s:5  
  :"grup";s:5:"vizualizări";}s:25:"views_plugins_pager_alter";a:1:{s:5:"grup";s:5:"vizualizări";}s:25:"views_plugins_query_alter „;a:1:{s:5:„grup”;s:  
  5:"views";}s:32:"views_plugins_relationship_alter";a:1:{s:5:"grup";s:5:"views";}s:23:"views_plugins_row_alter";a:1:{ s:5:"grup";s:5:"vie  
  ws";}s:24:"views_plugins_sort_alter";a:1:{s:5:"grup";s:5:"views";}s:25:"views_plugins_style_alter";a:1:{s:5 :"grup";s:5:"vizualizări";}s:26:"v  
  iews_plugins_wizard_alter";a:1:{s:5:"grup";s:5:"vizualizări";}s:25:"views_query_substitutions";a:1:{s:5:"grup";s:15: "views_execution";}s:24:"  
  views_form_substitutions";a:1:{s:5:"grup";s:15:"views_execution";}s:14:"views_pre_view";a:1:{s:5:"grup";s:15: "views_execution";}s:15:"v  
  iews_pre_build";a:1:{s:5:"grup";s:15:"views_execution";}s:16:"views_post_build";a:1:{s:5:"grup";s:15: "views_execution";}s:17:"views_pre  
  _execute";a:1:{s:5:"grup";s:15:"views_execution";}s:18:"views_post_execute";a:1:{s:5:"grup";s:15: "views_execution";}s:16:"views_pre_ren  
  der";a:1:{s:5:"grup";s:15:"views_execution";}s:17:"views_post_render";a:1:{s:5:"grup";s:15: "views_execution";}s:17:"views_query_alter";  
  a:1:{s:5:"group";s:15:"views_execution";}s:16:"field_views_data";a:1:{s:5:"group";s:5:"vizualizări" ;}s:22:"field_views_data_alter";a:1:{s:5:"gr  
  oup";s:5:"vizualizări";}}                                                                                                                        
      [:db_insert_placeholder_6] => 1                                                                                                        
  ) 

Am citit cateva solutii la actualizați entitățile, dar comanda drush nu mai este menținută.

Rulați drush updb

Rulați Drush Entup
Puncte:3
drapel nr

Există două părți ale migrației: baza de date și fișierele statice.

Cea mai importantă parte este baza de date. Veți avea nevoie de o copie de rezervă a bazei de date (alias sqldump) din baza de date de producție și va trebui să-l importați în baza de date locală.Există mai multe modalități de a realiza acest lucru, în funcție de găzduirea site-ului dvs. și dacă puteți utiliza sau nu drush.

Site-ul local ar trebui să fie oarecum funcțional după importul unei baze de date, dar poate părea ciudat dacă îi lipsesc elemente statice, cum ar fi fișierele imagine. În funcție de modul în care este configurat site-ul de producție, probabil că puteți găsi majoritatea acestora în directorul de fișiere publice. Cea mai comună locație pentru aceste fișiere este ./web/sites/default/files dar calea poate diferi. Va trebui să copiați aceste fișiere de pe gazda web de producție în mediul dvs. local folosind un instrument precum rsync, scp, sau sftp.

Dacă ați instalat Drush (prin compozitorul necesită drush/drush) atunci este posibil să puteți utiliza drush sql:sync pentru a sincroniza bazele de date.

Înainte de a face asta, poate doriți să configurați Aliasuri Drush pentru medii locale și îndepărtate.

Ține minte, de asemenea, că drush migra este utilizat în alt scop -- migrarea conținutului site-ului de pe o altă platformă non-Drupal în site-ul dvs. Drupal.

Ca experiment de gândire, să presupunem că aveți trei copii ale site-ului dvs. Drupal -- Dev, Stage și Prod -- pe un singur server (folosind trei Apache2 diferite VirtualHosts cu DocumentRoot setat la /var/www/dev, /var/www/stg, și /var/www/prd).

În acest caz, puteți folosi sincronizare_locală funcție definită mai jos pentru a sincroniza baza de date și fișierele dintr-un mediu superior într-un mediu inferior:

#!/bin/bash
â
function local_drush () {
  dacă [[ $# -eq 0 ]]; atunci
    echo "local_drush (setați mediul și executați proiectul-drush local)"
    echo „Utilizare: local_drush [dev stg prd] [drush-args]”
    echo „Setează mediul la dev stg sau prod, apoi trece argv la drush local.”
  fi
  dacă [[ $1 == 'dev' ]] || [[ $1 == 'stg' ]] || [[ $1 == 'prd' ]]; atunci
    RETURN_DIR=${PWD}
    cd /var/www/$1
    ./vendor/bin/drush ${@:2}
    cd ${RETURN_DIR}
  altfel
    echo „Utilizare nevalidă: primul argument trebuie să fie dev, stg sau prd.”
  fi
}
â
function local_sync () {
    dacă [[ $# -lt 1 ]] || [[ $# -gt 2 ]]; atunci
    echo "local_sync (migrați db și fișiere într-un mediu mai scăzut)"
    echo "Utilizare: local_sync <SOURCE> <TARGET>"
    echo „Setați mediile sursă și țintă, apoi sincronizați db și fișiere”.
  fi
  dacă [[ $1 == 'prd' ]] || [[ $1 == 'stg' ]]; atunci
    SURSA=1 USD
    dacă [[ $2 == 'stg' ]] || [[ $2 == 'dev' ]]; atunci
      ȚINTĂ=2 USD
      dacă [[ ( $1 = 'prd' && $2 == 'stg' ) || ( $1 = 'prd' && $2 == 'dev' ) || ( $1 = 'stg' && $2 == 'dev' ) ]]; atunci
        RETURN_DIR=${PWD}
        BACKUP_DIR=$HOME/sqldumps/${SOURCE}
        BACKUP_FILE=${BACKUP_DIR}/${SOURCE}_$(data -I).sql
        mkdir -p ${BACKUP_DIR}
        SOURCE_FILES=/var/www/${SOURCE}/web/sites/default/files/
        TARGET_FILES=/var/www/${TARGET}/web/sites/default/files/
        EXCLUDE_CSS=${SOURCE_FILES}css/
        EXCLUDE_JS=${SOURCE_FILES}js/
        EXCLUDE_PHP=${SOURCE_FILES}php/
â
        echo „Se creează o copie de rezervă temporară a bazei de date a mediului ${SOURCE}...”
        local_drush ${SOURCE} sql:dump > ${BACKUP_FILE}
â
        dacă [[ -s „${BACKUP_FILE}” ]]; atunci
          echo „Se importă backupul bazei de date în mediul ${TARGET}...”
          local_drush ${TARGET} sqlc < ${BACKUP_FILE}
          echo „Implementarea configurației în etape pentru mediul ${TARGET}...”
          local_drush ${TARGET} implementare
          echo „Se copiază fișiere publice din ${SOURCE} în ${TARGET}...”
          rsync --exclude ${EXCLUDE_CSS} \
          --exclude ${EXCLUDE_JS} \
          --exclude ${EXCLUDE_PHP} \
          --delete --progress -av ${SOURCE_FILES} ${TARGET_FILES}
          echo „Reconstituirea cache-urilor Drupal pentru mediul ${TARGET}...”
          local_drush ${TARGET} cache:rebuild
          echo „Importul de la ${SOURCE} în ${TARGET} a fost finalizat cu succes.”
          echo „Se elimină backupul bazei de date a mediului ${SOURCE}...”
          rm ${BACKUP_FILE}
          cd ${RETURN_DIR}
        altfel
          echo „Eroare: ${BACKUP_FILE} nu a fost găsit, nu poate continua.”
        fi
      altfel
        echo "Utilizare nevalidă: nu se poate copia din ${SOURCE} în ${TARGET}."
      fi
    altfel
      echo „Utilizare nevalidă: al doilea argument trebuie să fie stg sau dev.”
    fi
  altfel
    dacă [[ $1 == 'dev' ]]; atunci
      echo „Utilizare nevalidă: nu se poate migra de la dev la un mediu superior.”
    altfel
      echo "Utilizare nevalidă: primul arg trebuie să fie prd sau stg."
    fi
  fi
}

Rețineți că sincronizare_locală comanda depinde de local_drush comandă, care, la rândul său, depinde de proiectele locale și de la distanță care conțin un Drush in local de site ./vendor/bin/drush, care este metoda recomandată de instalarea Drush. Scriptul shell nu este standard, dar are avantajul de a funcționa indiferent dacă ați configurat sau nu aliasurile Drush corect.

Vă voi lăsa pe seama dvs. ca un exercițiu pentru a vă da seama cum să introduceți fișierele de pe serverul dvs. la distanță în mediul local. Nu este nimic greșit în a face toți acești pași manual sau în a folosi Filezilla pentru a transfera fișiere prin SFTP prin SSH, dar luați în considerare că rsync comanda (la liniile 49-52) poate fi folosită cu o altă comandă ${SOURCE} care poate fi pe un server la distanță. Singura altă schimbare pe care ar trebui să o faci ar fi și să faci rsync cel ${BACKUP_FILE} la localul dvs. (în jurul liniei 42).

Ha! Văd că ți-ai editat întrebarea în timp ce îmi scriam răspunsul.

Noua ta întrebare este un duplicat, răspuns Aici de Clive.

Din comentariile la acel răspuns:

Modul oficial este pentru modulele care se bazează pe vechea modalitate de a scrie în mod explicit codul pentru a face actualizările să aibă loc în hook_update_N. Toate detaliile serioase sunt aici: https://drupal.org/node/3034742

Soluția este să instalați Actualizări de entitate de dezvoltare modul, care face vechiul drush entup comanda disponibila.

Nu ar trebui să utilizați acest lucru în producție, dar este în regulă să îl utilizați în mediul dvs. de dezvoltare locală, atâta timp cât nu promovați DB local în mediul de producție.

Se pare că aveți această problemă doar în localul dvs., nu în producție, așa că această opțiune poate funcționa pentru dvs.

Noroc!

Renato Francia avatar
drapel id
Mulțumesc! Apreciez acest feedback
hotwebmatter avatar
drapel nr
Bucuros sa ajut! Dacă răspunsul meu vă rezolvă problema, asigurați-vă că o acceptați făcând clic pe bifa verde.
Puncte:2
drapel id

Ok, am reușit să o fac destul de ușor cu depozitele de drush.

Mai întâi, am făcut un dump pe serverul live cu:

drush sql:dump > db.sql

Și apoi în mediul meu docker.

Mai întâi m-am asigurat că elimin tabelele din baza de date de la Phpmyadmin.

Apoi am intrat în imaginea docker.

docker container exec -it <docker-container-id> bash

Și apoi rulați drush cu numele bazei de date pe care am aruncat-o din live (folosesc filezilla pentru a o transfera la dezvoltatorul meu local).

drush sql:cli < db.sql

Asigurați-vă că descărcați fișierele publice cu imaginile și le adăugați în folderul fișiere în local.

Am creat mai întâi site-ul și setările cu un site gol. Apoi, a adăugat doar imaginile, deoarece înlocuirea css, js și php generate în fișiere a creat probleme.

Sper că acest lucru vă ajută.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.