|
|
5 years ago | |
|---|---|---|
| bbdd | 5 years ago | |
| docs | 5 years ago | |
| httpdocs | 5 years ago | |
| scripts | 5 years ago | |
| tests | 5 years ago | |
| ISSUES.md | 5 years ago | |
| LICENSE | 5 years ago | |
| NORMAS.md | 5 years ago | |
| README.md | 5 years ago | |
| changelog.txt | 5 years ago | |
| deploy.sh | 5 years ago | |
| flushcache.php | 5 years ago | |
README.md
Licitator v1.0
Proyecto en Symfony 4.4 para el Servicio de Gestion de Desarrollos Digitales del Principado de Asturias
Especificaciónes de servidor
Hardware
Procesador 1.4 GHz Intel 64 o AMD 64 o superior con 2 CPUs o nucleos Tarjeta de red Gigabyte 4GB RAM o superior 40 GB de espacio o más, el espacio dependerá de la cantidad de archivos que se prevea almacenar en el servidor.
Software
Php 7.3 o superior MySql 5.7 o MariaDb 10.2 o superior Servidor web Apache 2.4 o Nginx 1.16 o superior (La configuración del servidor varía). Acceso ssh al servidor (para instalación y configuración)
Instalación
La instalación consta de varios pasos sucesivos automatizables mediante un script. Diferenciamos entre instalación automática y manual.
Descargar repositorio
Descargamos el repositorio bien por ssh:
git clone [Repositorio] [carpeta local donde se clonara]
o por https:
git clone https://[user]@[Repositorio] [carpeta local donde se clonara]
Tras esto entramos en la carpeta:
cd [carpeta local donde se clonara]/httpdocs
Instalación Automatica
Ejecutar el comando situado en la carpeta scripts del repositorio.
deploy.sh [carpeta de instalación] [nueva base de datos] [usuario base de datos] [password base de datos]
Instalación Manual
La instalación manual realiza exactamente los mismos pasos que la automática.
Crear la base de datos
Una vez realizado el install, procedemos a crear la base de datos donde:
- nombre-bbdd: Nombre de la Base de Datos
- usuario: Usuario de la máquina
- -p: Contraseña del usuario si tuviera
mysql -u usuario -p -e "create database nombre-bbdd;"
Si hubiera alguna dificultad al hacerlo mediante comando podemos creala con cualquier cliente Mysql.
CHAT, Mercure
Para el chat se está usando el componente mercure incluido en symfony. Para gestionar conexiones persistentes, Mercure confía en un Hub: un servidor dedicado que maneja conexiones SSE persistentes con los clientes. La aplicación Symfony publica las actualizaciones en el Hub, que las transmitirá a los clientes.
Hay que descargar una implementación oficial y de código abierto (AGPL) de un Hub de Mercure.rocks.
Debemos incluir estos parámetros en nuestro archivo .env o .env.local
MERCURE_PUBLISH_URL=http://localhost:3000/.well-known/mercure
MERCURE_JWT_TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJtZXJjdXJlIjp7InB1Ymxpc2giOltdfX0.Oo0yg7y4yMa1vr_bziltxuTCqb8JVHKxp-f_FwwOim0
En MERCURE_PUBLISH_URL inluiremos la url y el puerto de acceso a nuestro Hub mercure, seguido de /.well-known/mercure.
El otro parámetro es el MERCURE_JWT_TOKEN se pueden crear y firmar tokens JWT en está página jwt.io
El JWT debe estar firmado con la misma clave secreta que la utilizada por el Hub para verificar el JWT (! ChangeMe! En nuestro ejemplo). El cuerpo del JWT debe contener al menos la siguiente estructura para poder publicar:
{
"mercure": {
"publicar": []
}
}
Una vez instalado el HUB hay que ejecutar este comando para arrancarlo.
./mercure --jwt-key='!ChangeMe!' --addr='localhost:3000' --allow-anonymous --cors-allowed-origins='*'
!ChangeMe! es la key con la que está firmado el token de desarrollo incluido en el archivo .env en el atributo MERCURE_JWT_TOKEN, en el caso de usar otra key para firmar el token deberemos usar esta última en el parámetro --jwt-key del comando al iniciar el Hub, de otro modo los mensajes no se recibiran correctamente.
Una vez creada la base de datos configuramos nuestro fichero local de entorno con las siguientes variables:
- Conexión DDBB
- Tipo de entorno de trabajo
- Desarrollo: dev
- Produccion: prod
- Test: test
- Indicar el idioma por defecto de aplicación, en este caso sería:
- Español: es
- Inglés: en
- Tipo de correo electrónico
- Dirección de correo electrónico
- Nombre del FROM
echo "DATABASE_URL=mysql://root:@127.0.0.1:3306/nombre-bbdd" > .env.local
echo "APP_ENV=prod" >> .env.local
echo "APP_LOCALE=es" >> .env.local
echo "APP_SECRET=0a965b54faef5f2766f9ca1a2285abf2" >> .env.local
echo "MAILER_URL='gmail://prometeo.tests:#Pr0met3o&2019^@gmail.com?encryption=tls'" >> .env.local
echo "MAILER_ADDRESS=prometeo.tests@gmail.com" >> .env.local
echo "MAILER_SENDER_NAME='Prometeo Innovations S.L.N.E.'" >> .env.local
Instalar Composer
Ejecutamos:
- OJO composer se ejecutara con la versión base de php instaldada en el servidor si queremos usar una versión diferente deberemos preceder este comando con la version de php que queramos.
composer install
Para instalar todas las dependencias de los paquetes. En caso de insuficiencia de memoria ejecutar:
php -d memory_limit=-1 composer install
Ajustando rutas en caso de ser necesario. (Ej, con rutas absolutas para php y/o composer).
Dependencias propias
- OJO
Este proyecto tiene dos repositorios propios o modificados para ajustarse a nuestras necesidades. Estos dos repos se encuentran en la carpeta repositories, en el caso de realizar algun cambio en en cualquiera de ellos hay que actualizar la version en el archivo composer.json del/los repositorio/s en cuestion y ejecutarcomposer update paquete/nombre-del-repopara actualizar los cambios en la carpeta vendor.
Actualizar la base de datos
Actualizamos el esquema de la base de datos.
php bin/console doctrine:schema:update --force --dump-sql
Cargamos las fixtures
Dentro de las fixtures se incluyen los usuarios
- administrador
- editor
- test
- caso_estudio_%locale% : existen tantos usuarios caso_estudio como idiomas se hayan configurado.
php bin/console doctrine:fixtures:load --env dev
Generar usuario administrador (opcional)
Si, por cualquier cosa no queremos cargar las fixtures con los usuarios podemos crear el usuario administrador con el siguiente comando:
php bin/console fos:user:create [nombreusuario] --super-admin
Generar assets
Una vez completada la instalación base debemos generar los assets o archivos estáticos de cada uno de los módulo para que sean accesibles desde symfony.NOTA: EL ORDEN ES IMPORTANTE.
php bin/console ckeditor:install
php bin/console assets:install
php bin/console elfinder:install
#Ajustar permisos# Una vez instalado todo ajustamos los permisos
sudo chmod -R 777 vendor
sudo chmod -R 777 var
sudo chmod -R 777 public
sudo chmod -R 755 bin
###Configuraciones varias Para que la landing de acdr cargue los contadores de la home hay que habilitar el CORS, se puede hacer en el archivo httpdocs/public/.htaccess añadiendo las siguientes lineas
Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Methods "GET"
Header set Access-Control-Allow-Headers "Content-Type, Authorization"
en el caso de que el servidor funcione con php-fpm debemos saber que php-fpm anula los headers del htaccess, esto se soluciona introduciendo las lineas anteriores en la configuracion del host.
DESARROLLO / Actualizaciones del código fuente (Provisional)###
Si nuestras entidades / BBDD sufren modificaciones en su esquema debemos de realizar las siguientes operaciones
- Actualizar la nueva estructura de la BBDD en el skipper y realizar la correspondiente Export to ORM
- En las entidades User y Rule meter la propia clase en el DiscriminatorMap
- Regenerar las entidades
php bin/console make:entity --regenerate
- Crear una nueva versión de las migraciones para ello se debe ejecutar.
php bin/console doctrine:migrations:diff
- Verificar que el nuevo esquema de la BBDD sea válido.
php bin/console doctrine:schema:validate
- Actualizar la estructura de la BBDD.
php bin/console doctrine:migrations:migrate
- Verificar que no queda ninguna actualización pendiente.
php bin/console doctrine:schema:update --dump-sql
- Crear las nuevas fixtures si fuera necesario.
- Crear Backup de BBDD.
mysqldump -u root database_name | gzip -c > data.sql.gz
mysqldump -u root database_name -D > nodata.sql
- Commitear los cambios git
git add -A
git commit -a -m "Cambios en la BBDD (stable)
```cast