One place for hosting & domains

      unidades

      Cómo usar Systemctl para gestionar servicios y unidades de Systemd


      Introducción

      systemd es un sistema init y un administrador del sistema que se ha convertido en el nuevo estándar para las distribuciones Linux. Debido a su gran adopción, merece la pena familiarizarse con systemd, ya que hará que administrar servidores sea mucho más fácil. Conocer y utilizar las herramientas y daemons que componen systemd le ayudará a apreciar mejor la potencia, la flexibilidad y las capacidades que proporciona, o al menos a simplificar su trabajo.

      En esta guía, hablaremos del comando systemctl, que es la herramienta de administración central para controlar el sistema init. Explicaremos cómo administrar servicios, comprobar estados, cambiar estados del sistema y trabajar con los archivos de configuración.

      Tenga en cuenta que aunque systemd es el sistema init predeterminado para muchas distribuciones Linux, no se implementa universalmente en todas las distribuciones. A medida que avanza en este tutorial, si su terminal arroja el error bash: systemctl is not installed, es probable que su equipo tenga un sistema init diferente instalado.

      Administración de servicios

      La finalidad principal de un sistema init es inicializar los componentes que deben iniciarse tras arrancar el kernel Linux (tradicionalmente conocidos como componentes “userland”). El sistema init también se utiliza para administrar servicios y daemons para el servidor en cualquier momento mientras se ejecuta el sistema. Teniendo eso en cuenta, comenzaremos con algunas operaciones básicas de administración de servicio.

      En systemd, el destino de la mayoría de las acciones son “unidades”, que son recursos que systemd sabe cómo administrar. Las unidades se categorizan por el tipo de recurso al que representan y se definen con archivos conocidos como archivos de unidad. El tipo de cada unidad puede deducirse del sufijo al final del archivo.

      Para las tareas de administración de servicio, la unidad de destino será unidades de servicio, que tienen archivos de unidad con un sufijo .service. Sin embargo, para la mayoría de los comandos de administración de servicio, puede dejar fuera el sufijo .service, ya que systemd es lo suficientemente inteligente para saber que probablemente quiere operar sobre un servicio cuando utiliza comandos de administración de servicio.

      Iniciar y detener servicios

      Para iniciar un servicio systemd, ejecutar instrucciones en el archivo de la unidad del servicio, utilice el comando start. Si está ejecutando como usuario non-root, tendrá que usar sudo, ya que esto afectará al estado del sistema operativo.

      • sudo systemctl start application.service

      Como hemos mencionado antes, systemd sabe buscar los archivos *.service para los comandos de administración de servicio, de forma que el comando podría escribirse fácilmente así:

      • sudo systemctl start application

      Aunque puede usar el formato anterior para la administración general, para mayor claridad, usaremos el sufijo .service para el resto de los comandos, con el objetivo de ser explícitos sobre el destino en el que estamos operando.

      Para detener un servicio que se esté ejecutando actualmente, puede usar el comando stop:

      • sudo systemctl stop application.service

      Reiniciar y volver a cargar

      Para reiniciar un servicio en ejecución, puede usar el comando restart:

      • sudo systemctl restart application.service

      Si la aplicación en cuestión puede volver a cargar sus archivos de configuración (sin reiniciar), puede emitir el comando reload para iniciar ese proceso:

      • sudo systemctl reload application.service

      Si no está seguro de si el servicio tiene la funcionalidad de volver a cargar su configuración, puede emitir el comando reload-or-restart. Esto volverá a cargar la configuración en vigor, si está disponible. De lo contrario, reiniciará el servicio de forma que se recoja la nueva configuración:

      • sudo systemctl reload-or-restart application.service

      Cómo habilitar y deshabilitar servicios

      Los comandos anteriores son útiles para iniciar o detener servicios durante la sesión actual. Para indicar a systemd que inicie servicios automáticamente en el arranque, debe habilitarlos.

      Para iniciar un servicio en el arranque, utilice el comando enable:

      • sudo systemctl enable application.service

      Esto creará un enlace simbólico desde la copia del sistema del archivo de servicio (normalmente en /lib/systemd/system o /etc/systemd/system) en la ubicación del disco donde systemd busca los archivos de inicio automático (normalmente /etc/systemd/system/some_target.target.wants. Repasaremos qué es un destino más adelante en esta guía).

      Para impedir que el servicio se inicie automáticamente, puede escribir:

      • sudo systemctl disable application.service

      Esto eliminará el enlace simbólico que indicaba que el servicio debía iniciarse automáticamente.

      Tenga en cuenta que habilitar el servicio no lo inicia en la sesión actual. Si desea iniciar el servicio y habilitarlo en el arranque, tendrá que emitir los comandos start y enable.

      Cómo comprobar el estado de los servicios

      Para comprobar el estado de un servicio en su sistema, puede usar el comando status:

      • systemctl status application.service

      Esto le proporcionará el estado del servicio, la jerarquía de cgroup y las primeras líneas de registro.

      Por ejemplo, cuando se comprueba el estado de un servidor Nginx, puede ver un resultado como este:

      Output

      ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago Main PID: 495 (nginx) CGroup: /system.slice/nginx.service ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr; └─496 nginx: worker process Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server... Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

      Esto le proporciona una buena visión general del estado actual de la aplicación, y le notifica de cualquier problema y cualquier acción que pueda ser necesaria.

      También hay métodos para comprobar los estados específicos. Por ejemplo, para comprobar si una unidad está activa actualmente (ejecutándose) puede usar el comando is-active:

      • systemctl is-active application.service

      Esto devolverá el estado actual de la unidad, que es normalmente activo o inactivo. El código de salida será “0” si está activo, lo que hace que el resultado sea más sencillo de analizar en las secuencias de comando shell.

      Para ver si la unidad está habilitada, puede usar el comando is-enabled:

      • systemctl is-enabled application.service

      Esto indicará si el servicio está habilitado o deshabilitado y establecerá el código de salida a “0” o “1”, dependiendo de la respuesta a la pregunta del comando.

      Una tercera comprobación es si la unidad está en estado fallido. Esto indica que hubo un problema al iniciar la unidad en cuestión:

      • systemctl is-failed application.service

      Esto devolverá active si se está ejecutando adecuadamente o failed si se ha producido un error. Si la unidad se detuvo intencionadamente, puede devolver unknown o inactive. Un estado de salida de “0” indica que se produjo un error y un estado de salida de “1” indica cualquier otro estado.

      Descripción general del estado del sistema

      Los comandos hasta ahora han sido útiles para administrar servicios individuales, pero no son muy útiles para explorar el estado actual del sistema. Hay varios comandos systemctl que proporcionan esta información.

      Cómo enumerar las unidades actuales

      Para ver una lista de todas las unidades activas que systemd conoce, podemos usar el comando list-units:

      Esto le mostrará una lista de todas las unidades que systemd tiene activas actualmente en el sistema. El resultado tendrá un aspecto similar a este:

      Output

      UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running ATD daemon avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack dbus.service loaded active running D-Bus System Message Bus dcron.service loaded active running Periodic Command Scheduler dkms.service loaded active exited Dynamic Kernel Modules System [email protected] loaded active running Getty on tty1 . . .

      El resultado tiene las siguientes columnas:

      • UNIT: El nombre de la unidad de systemd
      • LOAD: Si la configuración de la unidad ha sido analizada por systemd. La configuración de las unidades cargadas se mantiene en la memoria.
      • ACTIVE: Un estado resumido que indica si la unidad está activa. Esta es normalmente una forma bastante básica de saber si la unidad se ha iniciado correctamente o no.
      • SUB: Este es un estado de nivel inferior que indica información más detallada sobre la unidad. Esto a menudo varía por tipo de unidad, estado y el método real en el que se ejecuta la unidad.
      • DESCRIPTION: Una descripción textual breve de qué es y hace la unidad.

      Ya que el comando list-units muestra solo las unidades activas por defecto, todas las entradas por encima se mostrarán loaded en la columna LOAD y active en la columna ACTIVE. Esta pantalla es, en realidad, el comportamiento predeterminado de systemctl cuando se invoca sin comandos adicionales, de modo que verá lo mismo si invoca systemctl sin argumentos:

      Podemos indicar a systemctl que produzca información diferente añadiendo marcadores adicionales. Por ejemplo, para ver todas las unidades que systemd ha cargado (o intentado cargar), independientemente de si están activas actualmente, puede usar el marcador --all, de esta forma:

      • systemctl list-units --all

      Esto mostrará cualquier unidad que systemd haya cargado o intentado cargar, independientemente de su estado actual en el sistema. Ciertas unidades se vuelven inactivas tras ejecutarse, y algunas de las unidades que systemd intentó cargar pueden no haberse encontrado en el disco.

      Puede usar otros marcadores para filtrar estos resultados. Por ejemplo, puede usar el indicador --state= para indicar los estados LOAD, ACTIVE o SUB que deseamos ver. Tendremos que mantener el marcador --all para que systemctl permita que se muestren las unidades no activas:

      • systemctl list-units --all --state=inactive

      Otro filtro común es el filtro --type=. Podemos indicar a systemctl que solo muestre unidades del tipo en el que estemos interesados. Por ejemplo, para ver únicamente las unidades de servicio activas, podemos usar:

      • systemctl list-units --type=service

      Listar todos los archivos de la unidad

      El comando list-units solo muestra las unidades que systemd ha intentado analizar y cargar en la memoria. Ya que systemd solo leerá unidades que cree que necesita, esto no incluirá necesariamente todas las unidades disponibles en el sistema. Para ver todos los archivos de unidad disponibles en las rutas systemd, incluidos aquellos que systemd no haya intentado cargar, puede usar el comando list-unit-files:

      • systemctl list-unit-files

      Las unidades son representaciones de los recursos que systemd conoce. Ya que systemd no ha leído necesariamente todas las definiciones de la unidades en esta vista, solo presente información sobre los propios archivos. El resultado tiene dos columnas, el archivo de la unidad y el estado.

      Output

      UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount static proc-fs-nfsd.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount static var-lib-nfs-rpc_pipefs.mount static org.cups.cupsd.path enabled . . .

      El estado normalmente estará habilitado, deshabilitado, estático o enmascarado. En este contexto, “estático” significa que el archivo de unidad no contiene una sección install, que se utiliza para habilitar una unidad. Como tal, estas unidades no pueden habilitarse. Normalmente, esto significa que la unidad realiza una única acción o se utiliza solo como dependencia de otra unidad y no debería ejecutarse por sí misma.

      En breve explicaremos lo que significa enmascarado.

      Gestión de la unidad

      Hasta ahora, hemos estado trabajando con servicios y mostrando información sobre la unidad y los archivos de la unidad que systemd conoce. Sin embargo, encontraremos más información específica sobre las unidades usando algunos comandos adicionales.

      Mostrar un archivo de unidad

      Para mostrar el archivo de unidad que systemd ha cargado en su sistema, puede usar el comando cat (esto se añadió en la versión 209 de systemd). Por ejemplo, para ver el archivo de unidad del daemon de programación atd, podríamos escribir:

      • systemctl cat atd.service

      Output

      [Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target

      El resultado es el archivo de unidad tal como lo conoce el proceso systemd que se está ejecutando actualmente. Esto puede ser importante si ha modificado archivos de unidad recientemente o si está omitiendo ciertas opciones en un fragmento del archivo de unidad (hablaremos de esto más tarde).

      Mostrar dependencias

      Para ver el árbol de dependencias de una unidad, puede usar el comando list-dependencies:

      • systemctl list-dependencies sshd.service

      Esto mostrará una jerarquía asignando las dependencias que deben tratarse para iniciar la unidad en cuestión. Las dependencias, en este contexto, incluyen las unidades que son necesarias o deseadas por unidades de nivel superior.

      Output

      sshd.service ├─system.slice └─basic.target ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target . . .

      Las dependencias recursivas solo se muestran para las unidades .target, que indican los estados del sistema. Para listar de forma recursiva todas las dependencias, incluya el indicador --all.

      Para mostrar las dependencias inversas (unidades que dependen de la unidad especificada) puede añadir el indicador --reverse al comando. Otros indicadores que son útiles son los indicadores --before y --after, que pueden usarse para mostrar las unidades que dependen de la unidad especificada que comienza antes y después de ellas mismas respectivamente.

      Comprobar las propiedades de la unidad

      Para ver las propiedades de nivel bajo de una unidad, puede usar el comando show. Esto mostrará una lista de propiedades que se establecen para la unidad especificada usando un formato key=value:

      • systemctl show sshd.service

      Output

      Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon . . .

      Si desea mostrar una única propiedad, pude pasar el indicador -p con el nombre de la propiedad. Por ejemplo, para ver los conflictos que la unidad sshd.service tiene, puede escribir:

      • systemctl show sshd.service -p Conflicts

      Output

      Conflicts=shutdown.target

      Enmascarar y desenmascarar unidades

      Vimos en la sección de administración del servicio cómo detener o deshabilitar un servicio, pero systemd también tiene la capacidad de marcar una unidad como completamente no iniciable, automática o manualmente, vinculándola a /dev/null. Esto se denomina enmascarar la unidad, y es posible con el comando mask:

      • sudo systemctl mask nginx.service

      Esto impedirá que el servicio Nginx se inicie, automática o manualmente, siempre que esté enmascarado.

      Si comprueba los list-unit-files, verá que el servicio ahora se lista como enmascarado:

      • systemctl list-unit-files

      Output

      . . . kmod-static-nodes.service static ldconfig.service static mandb.service static messagebus.service static nginx.service masked quotaon.service static rc-local.service static rdisc.service disabled rescue.service static . . .

      Si intenta iniciar el servicio, verá un mensaje como este:

      • sudo systemctl start nginx.service

      Output

      Failed to start nginx.service: Unit nginx.service is masked.

      Para desenmascarar una unidad, y hacer que esté disponible de nuevo para su uso, utilice el comando unmask:

      • sudo systemctl unmask nginx.service

      Esto devolverá la unidad a su estado anterior, permitiendo que se inicie o habilite.

      Editar archivos de la unidad

      Aunque el formato específico de los archivos de unidad está fuera del alcance de este tutorial, si necesita realizar ajustes, systemctl proporciona mecanismos integrados para editar y modificar archivos de unidad. Esta funcionalidad fue añadida en la versión 218 de systemd.

      El comando edit, por defecto, abrirá un fragmento de código del archivo de la unidad para la unidad en cuestión:

      • sudo systemctl edit nginx.service

      Este será un archivo en blanco que puede usarse para omitir o añadir directivas a la definición de la unidad. Se creará un directorio en el directorio /etc/systemd/system que contiene el nombre de la unidad con .d anexada. Por ejemplo, para el nginx.service, se creará un directorio llamado nginx.service.d.

      En este directorio, se creará un fragmento de código llamado override.conf. Cuando se carga la unidad, systemd, en la memoria, fusionará el fragmento de código de anulación con el archivo de unidad completo. Las directivas del snippet prevalecerán sobre las encontradas en el archivo original de la unidad.

      Si desea editar el archivo completo de la unidad en vez de crear un fragmento de código, puede pasar el indicador --full:

      • sudo systemctl edit --full nginx.service

      Esto cargará el archivo de unidad actual en el editor, donde se podrá modificar. Cuando sale el editor, el archivo cambiado se escribirá a /etc/systemd/system, que tendrá prioridad sobre la definición de la unidad del sistema (normalmente se encuentra en algún lugar de /lib/systemd/system).

      Para eliminar cualquier adición que haya realizado, elimine el directorio de configuración .d de la unidad o el archivo de servicio modificado de /etc/systemd/system. Por ejemplo, para eliminar un fragmento de código, podríamos escribir lo siguiente:

      • sudo rm -r /etc/systemd/system/nginx.service.d

      Para eliminar un archivo de unidad completo modificado, escribiríamos:

      • sudo rm /etc/systemd/system/nginx.service

      Tras eliminar el archivo o directorio, debería volver a cargar el proceso systemd de forma que deje de intentar hacer referencia a estos archivos y vuelve a usar las copias del sistema. Puede hacerlo escribiendo lo siguiente:

      • sudo systemctl daemon-reload

      Ajustar el estado del sistema (Runlevel) con los destinos

      Los destinos son archivos de unidad especiales que describen el estado de un sistema o un punto de sincronización. Igual que otras unidades, los archivos que definen los destinos pueden identificarse por su sufijo, que en este caso es .target. Los destinos no hacen mucho por sí mismos, pero se utilizan para agrupar otras unidades.

      Esto puede usarse para llevar al sistema a ciertos estados, de forma muy similar que otros sistemas init utilizan runlevels. Se utilizan como referencia para cuando ciertas funciones estén disponibles, lo que le permite especificar el estado deseado en vez de las unidades individuales necesarias para producir ese estado.

      Por ejemplo, hay un swap.target que se usa para indicar que swap está listo para usarse. Las unidades que son parte de este proceso pueden sincronizarse con este destino indicando en su configuración que son WantedBy= o RequiredBy= el swap.target. Las unidades que requieren que swap esté disponible pueden especificar esta condición usando las especificaciones Wants=, Requires= y After= para indicar la naturaleza de su relación.

      Obtener y establecer el destino predeterminado

      El proceso systemd tiene un destino predeterminado que utiliza cuando se inicia el sistema. Satisfacer la cascada de dependencias de ese destino individual llevará al sistema al estado deseado. Para encontrar el destino predeterminado de su sistema, escriba:

      Output

      multi-user.target

      Si desea establecer un destino predeterminado diferente, puede usar set-default. Por ejemplo, si tiene un escritorio gráfico instalado y desea que el sistema se inicie a esto por defecto, puede cambiar el destino predeterminado:

      • sudo systemctl set-default graphical.target

      Cómo enumerar los destinos disponibles

      Puede obtener una lista de los destinos disponibles en su sistema escribiendo:

      • systemctl list-unit-files --type=target

      A diferencia de runlevels, puede haber múltiples destinos activos a la vez. Un destino activo indica que systemd ha intentado iniciar todas las unidades relacionadas con el destino y no ha intentado desglosarlas de nuevo. Para ver todos los destinos activos, escriba:

      • systemctl list-units --type=target

      Aislar destinos

      Es posible iniciar todas las unidades asociadas con un destino y detener todas las que no son parte del árbol de dependencias. El comando que necesitamos para hacer esto se denomina, apropiadamente, isolate. Esto es similar a cambiar el runlevel en otros sistemas init.

      Por ejemplo, si está operando en un entorno gráfico con graphical.target activo, puede apagar el sistema gráfico y poner el sistema en un estado de línea de comando multi usuario asilando el multi-user.target. Ya que graphical.target depende de multi-user.target pero no al revés, todas las unidades gráficas se detendrán.

      Quizá desee echar un vistazo a las dependencias del destino que está aislando antes de realizar este procedimiento para asegurarse de que no está deteniendo servicios cruciales:

      • systemctl list-dependencies multi-user.target

      Cuando esté satisfecho con las unidades que se mantendrán activas, puede aislar el destino escribiendo lo siguiente:

      • sudo systemctl isolate multi-user.target

      Cómo usar atajos para eventos importantes

      Existen destinos definidos para eventos importantes como apagar o reiniciar. Sin embargo, systemctl también tiene algunos atajos que añaden ciertas funciones adicionales.

      Por ejemplo, para poner el sistema en el modo rescate (usuario único), puede usar simplemente el comando rescue en vez de isolate rescue.target,

      Esto proporcionará la funcionalidad adicional de alertar a todos los usuarios con sesión iniciada sobre el evento.

      Para detener el sistema, puede usar el comando halt:

      Para iniciar un apagado completo, puede usar el comando poweroff:

      Puede iniciar un reinicio con el comando reboot:

      Todos estos comandos alertan a los usuarios con sesión iniciada de que se va a producir el evento, algo que ejecutar o aislar el destino únicamente no hará. Observe que la mayoría de los equipos vincularán los comandos más cortos y convencionales para estas operaciones de forma que funcionen adecuadamente con systemd.

      Por ejemplo, para reiniciar el sistema, normalmente puede escribir:

      Conclusión

      Ahora debería estar familiarizado con algunas de las capacidades básicas del comando systemctl que le permite controlar e interactuar con su instancia de systemd. La utilidad systemctl será su punto de interacción principal para la administración del estado del servicio y del sistema.

      Aunque systemctl opera principalmente con el proceso central systemd, hay otros componentes para el ecosistema de systemd que están controlados por otras utilidades. Otras capacidades, como la administración de registros y las sesiones de usuario se administran mediante daemons y utilidades de administración independientes (journald/journalctl y logind/loginctl, respectivamente). Al tomarse el tiempo para familiarizarse con estas herramientas y daemons, la administración le resultará más sencilla.



      Source link

      Como usar Systemctl para gerenciar serviços e unidades do systemd


      Introdução

      Systemd é um sistema init e gerenciador de sistema que se tornou o novo padrão para distribuições Linux. Devido à sua forte adoção, familiarizar-se com o systemd vale muito a pena, pois irá tornar a administração de servidores consideravelmente mais fácil. Aprender sobre as ferramentas e daemons que compõem o systemd e como usá-los irá ajudar a entender melhor o poder, flexibilidade e capacidades que ele oferece ou, pelo menos, facilitará o seu trabalho.

      Neste guia, vamos discutir o comando systemctl, que é a ferramenta de gerenciamento central para controlar o sistema init. Vamos abordar como gerenciar serviços, verificar status, alterar estados de sistema e trabalhar com os arquivos de configuração.

      Observe que embora o systemd tenha se tornado o sistema init padrão para muitas distribuições Linux, ele não é implementado universalmente em todas as distros. À medida que você percorrer este tutorial, se o seu terminal exibir o erro bash: systemctl is not installed, então é provável que sua máquina tenha um sistema init diferente instalado.

      Gerenciamento de serviços

      O objetivo fundamental de um sistema init é inicializar os componentes que devem ser iniciados após o kernel do Linux ser inicializado (tradicionalmente conhecido como componentes “userland”). O sistema init também é usado para gerenciar serviços e daemons para o servidor em qualquer momento enquanto o sistema está em execução. Com isso em mente, vamos começar com algumas operações básicas de gerenciamento de serviços.

      No systemd, o alvo da maioria das ações são “unidades”, que são os recursos que o systemd sabe gerenciar. As unidades são categorizadas pelo tipo de recurso que representam e são definidas com arquivos conhecidos como arquivos unit. O tipo de cada unidade pode ser inferido a partir do sufixo no final do arquivo.

      Para tarefas de gerenciamento de serviços, a unidade de destino serão unidades de serviço, que possuem arquivos de unidade com um sufixo .service. No entanto, para a maioria dos comandos de gerenciamento de serviços, é possível deixar o sufixo .service, pois o systemd é inteligente o suficiente para saber que você provavelmente deseja operar em um serviço ao usar comandos de gerenciamento de serviços.

      Iniciando e interrompendo os serviços

      Para iniciar um serviço systemd, executando instruções no arquivo de unidade do serviço, use o comando start. Caso esteja usando um usuário não root, você terá que usar o sudo, pois isso afetará o estado do sistema operacional:

      • sudo systemctl start application.service

      Como mencionamos acima, o systemd sabe procurar por arquivos *.service para comandos de gerenciamento de serviços, de forma que o comando poderia ser também digitado desta forma:

      • sudo systemctl start application

      Embora você possa usar o formato acima para a administração geral, para maior clareza, vamos usar o sufixo .service para o resto dos comandos, para sermos explícitos sobre o alvo em que estamos operando.

      Para parar um serviço que esteja atualmente em execução, use o comando stop:

      • sudo systemctl stop application.service

      Reiniciando e recarregando

      Para reiniciar um serviço em execução, use o comando restart:

      • sudo systemctl restart application.service

      Se o aplicativo em questão for capaz de recarregar seus arquivos de configuração (sem reiniciar), você pode emitir o comando reload para iniciar esse processo:

      • sudo systemctl reload application.service

      Se não tiver certeza se o serviço possui a funcionalidade para recarregar sua configuração, emita o comando reload-or-restart. Isso irá recarregar a configuração em vigor, se disponível. Caso contrário, o serviço será reiniciado para que a nova configuração seja ativada:

      • sudo systemctl reload-or-restart application.service

      Habilitando e desabilitando serviços

      Os comandos acima são úteis para iniciar ou interromper serviços durante a sessão atual. Para dizer ao systemd para iniciar serviços automaticamente na inicialização do sistema, é necessário habilitá-los.

      Para iniciar um serviço na inicialização, use o comando enable:

      • sudo systemctl enable application.service

      Isso irá criar um link simbólico a partir da cópia do arquivo de serviço do sistema (geralmente em /lib/systemd/system ou /etc/systemd/system) para a localização em disco onde o systemd procura por arquivos de inicialização automática (geralmente etc/systemd/system/some_target.target.wants. Vamos abordar o que é um alvo mais adiante neste guia).

      Para impedir que o serviço seja iniciado automaticamente, digite:

      • sudo systemctl disable application.service

      Isso irá remover o link simbólico que indica que o serviço deve ser iniciado automaticamente.

      Esteja ciente de que habilitar um serviço não o inicia na sessão atual. Se quiser iniciar o serviço e também habilitá-lo na inicialização, será necessário emitir ambos os comandos start e enable.

      Verificando o status de serviços

      Para verificar o status de um serviço em seu sistema, use o comando status:

      • systemctl status application.service

      Isso irá mostrar-lhe o estado do serviço, a hierarquia de cgroup e as primeiras linhas de registro.

      Por exemplo, ao verificar o status de um servidor Nginx, pode ser que você veja um resultado como este:

      Output

      ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago Main PID: 495 (nginx) CGroup: /system.slice/nginx.service ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr; └─496 nginx: worker process Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server... Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

      Isso oferece uma visão geral interessante do status atual do aplicativo, notificando você acerca de qualquer problema ou ação que possa ser necessária.

      Há também métodos para verificar por estados específicos. Por exemplo, para verifciar se uma unidade está ativa (em execução), use o comando is-active:

      • systemctl is-active application.service

      Isso irá retornar o estado da unidade atual, que geralmente é active ou inactive. O código de saída será “0” se for ativo, tornando o resultado mais simples de se analisar em scripts do shell.

      Para ver se uma unidade está habilitada, use o comando is-enabled:

      • systemctl is-enabled application.service

      Isso irá mostrar se o serviço está enabled ou disabled e irá definir novamente o código de saída como “0” ou “1”, dependendo da resposta para a pergunta do comando.

      Uma terceira verificação é se a unidade está em um estado de falha. Ele indica se houve um problema ao iniciar a unidade em questão:

      • systemctl is-failed application.service

      Isso irá retornar active se a unidade estiver executando corretamente ou failed caso um erro tenha ocorrido. Se a unidade tiver sido intencionalmente interrompida, ela pode retornar unknown ou inactive. Um status de saída de “0” indica que uma falha ocorreu, enquanto um status de saída de “1” indica qualquer outro status.

      Visão geral do estado do sistema

      Os comandos mostrados até agora têm sido úteis para o gerenciamento de serviços únicos, mas não são muito úteis para explorar o estado atual do sistema. Existem diversos comandos do systemctl que fornecem essa informação.

      Listando as unidades atuais

      Para ver uma lista com todas as unidades ativas das quais o systemd sabe, podemos usar o comando list-units:

      Isso irá mostrar-lhe uma lista de todas as unidades que o systemd possui como ativa atualmente no sistema. O resultado se parecerá com este:

      Output

      UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running ATD daemon avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack dbus.service loaded active running D-Bus System Message Bus dcron.service loaded active running Periodic Command Scheduler dkms.service loaded active exited Dynamic Kernel Modules System [email protected] loaded active running Getty on tty1 . . .

      O resultado possui as seguintes colunas:

      • UNIT: o nome da unidade de systemd
      • LOAD: se a configuração da unidade foi analisada pelo systemd. A configuração de unidades carregadas é mantida na memória.
      • ACTIVE: um estado resumido que diz se a unidade está ativa. Essa é geralmente uma maneira bastante simples de dizer se a unidade foi iniciada com sucesso ou não.
      • SUB: esse é um estado de nível mais baixo que indica informações mais detalhadas sobre a unidade. Isso muitas vezes varia dependendo do tipo de unidade, estado e do método em si com o qual a unidade é executada.
      • DESCRIPTION: uma breve descrição textual do que a unidade é/faz.

      Como o comando list-units mostra apenas unidades ativas por padrão, todas as entradas acima exibirão loaded na coluna LOAD e active na coluna ACTIVE. Essa exibição é na verdade o comportamento padrão do systemctl quando chamado sem comandos adicionais. Sendo assim, você irá ver a mesma coisa se chamar systemctl sem argumentos:

      Podemos dizer ao systemctl para mostrar outras informações adicionando sinalizadores adicionais. Por exemplo, para ver todas as unidades que o systemd carregou (ou tentou carregar), independentemente se estão ou não ativas, use o sinalizador --all, desta forma:

      • systemctl list-units --all

      Isso irá mostrar qualquer unidade que o systemd carregou ou tentou carregar, independentemente do seu estado atual no sistema. Algumas unidades tornam-se inativas após serem executadas, e algumas unidades que o systemd tentou carregar podem não ter sido encontradas em disco.

      Use outros sinalizadores para filtrar esses resultados. Por exemplo, é possível usar o sinalizador --state= para indicar os estados LOAD, ACTIVE ou SUB que desejamos ver. Será necessário manter o sinalizador --all para que o systemctl permita que unidades não ativas sejam exibidas:

      • systemctl list-units --all --state=inactive

      Outro filtro comum é o filtro --type=. Podemos dizer ao systemctl para exibir apenas unidades do tipo em que estamos interessados. Por exemplo, para ver apenas unidades de serviço ativas, podemos usar:

      • systemctl list-units --type=service

      Listando todos os arquivos de unidade

      O comando list-units exibe apenas unidades que o systemd tentou analisar e carregar na memória. Como o systemd irá ler apenas unidades as quais ele acha necessário, isso não incluirá necessariamente todas as unidades disponíveis no sistema. Para ver todos os arquivos de unidade disponíveis nos caminhos do systemd, incluindo aquelas que o systemd não tentou carregar, use o comando list-unit-files:

      • systemctl list-unit-files

      As unidades são representações de recursos sobre os quais o systemd sabe. Como o systemd não leu necessariamente todas as definições de unidade nesta visão, ele apresenta apenas informações sobre os arquivos em si. O resultado possui duas colunas: o arquivo de unidade e o estado.

      Output

      UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount static proc-fs-nfsd.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount static var-lib-nfs-rpc_pipefs.mount static org.cups.cupsd.path enabled . . .

      O estado normalmente será enabled, disabled, static ou masked. Neste contexto, estático significa que o arquivo de unidade não contém uma seção install, que é usada para habilitar uma unidade. Dessa forma, essas unidades não podem ser ativadas. Geralmente, isso significa que a unidade executa uma ação única ou é usada apenas como uma dependência de outra unidade e não deve ser executada sozinha.

      Vamos abordar o que masked significa daqui a pouco.

      Gerenciamento de unidades

      Até aqui, estivemos trabalhando com serviços e exibindo informações sobre a unidade e arquivos de unidade sobre os quais o systemd sabe. No entanto, é possível descobrir mais informações específicas sobre unidades usando alguns comandos adicionais.

      Exibindo um arquivo de unidade

      Para exibir o arquivo de unidade que o systemd carregou em seu sistema, use o comando cat (adicionado na versão 209 do systemd). Por exemplo, para ver o arquivo de unidade do daemon de planejamento atd, poderíamos digitar:

      • systemctl cat atd.service

      Output

      [Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target

      O resultado é o arquivo de unidade, da forma como é conhecido pelo processo do systemd atualmente em execução. Isso pode ser importante se você tiver arquivos de unidade modificados recentemente ou se estiver sobrepondo certas opções em um fragmento de arquivo de unidade (vamos falar disso mais tarde).

      Exibindo dependências

      Para ver a árvore de dependências de uma unidade, use o comando list-dependencies:

      • systemctl list-dependencies sshd.service

      Isso irá exibir uma hierarquia mapeando as dependências que devem ser tratadas para iniciar a unidade em questão. Dependências, neste contexto, incluem aquelas unidades que são exigidas ou procuradas pelas unidades acima dela.

      Output

      sshd.service ├─system.slice └─basic.target ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target . . .

      As dependências recursivas são exibidas apenas para unidades .target, que indicam estados do sistema. Para listar recursivamente todas as dependências, inclua o sinalizador --all.

      Para mostrar dependências reversas (unidades que dependem da unidade especificada), adicione o sinalizador --reverse ao comando. Outros sinalizadoras que são úteis são os sinalizadoras --before e --after, que podem ser usados para mostrar unidades que dependem da unidade especificada iniciando antes e depois de si mesmos, respectivamente.

      Verificando propriedades da unidade

      Para ver as propriedades de baixo nível de uma unidade, use o comando show. Ele irá exibir uma lista de propriedades que são definidas para a unidade especificada usando um formato key=value:

      • systemctl show sshd.service

      Output

      Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon . . .

      Se quiser exibir uma única propriedade, passe o sinalizador -p com o nome da propriedade. Por exemplo, para ver os conflitos que a unidade sshd.service possui, digite:

      • systemctl show sshd.service -p Conflicts

      Output

      Conflicts=shutdown.target

      Mascarando e desmascarando unidades

      Vimos na seção de gerenciamento de serviços como parar ou desativar um serviço. No entanto, o systemd também possui a capacidade de marcar uma unidade como absolutamente não iniciável, de modo automático ou manual, ligando-a ao /dev/null. Isso é chamado de mascarar a unidade, e é possível com o comando mask:

      • sudo systemctl mask nginx.service

      Isso irá impedir que o serviço Nginx seja iniciado, automaticamente ou manualmente, enquanto estiver mascarado.

      Se verificar o list-unit-files, verá que o serviço está agora listado como mascarado:

      • systemctl list-unit-files

      Output

      . . . kmod-static-nodes.service static ldconfig.service static mandb.service static messagebus.service static nginx.service masked quotaon.service static rc-local.service static rdisc.service disabled rescue.service static . . .

      Se você tentar iniciar o serviço, verá uma mensagem como esta:

      • sudo systemctl start nginx.service

      Output

      Failed to start nginx.service: Unit nginx.service is masked.

      Para desmascarar uma unidade, tornando-a disponível para uso novamente, use o comando unmask:

      • sudo systemctl unmask nginx.service

      Isso irá retornar a unidade ao seu estado anterior, permitindo que seja iniciada ou habilitada.

      Editando arquivos de unidade

      Embora o formato específico para arquivos de unidade esteja fora do âmbito deste tutorial, o systemctl fornece mecanismos integrados para editar e modificar arquivos de unidade, se for necessário fazer ajustes. Essa funcionalidade foi adicionada na versão 218do systemd.

      O comando edit, por padrão, irá abrir um trecho de código do arquivo de unidade para a unidade em questão:

      • sudo systemctl edit nginx.service

      Esse será um arquivo em branco que pode ser usado para substituir ou adicionar diretivas à definição da unidade. Um diretório será criado dentro do diretório /etc/systemd/system, que contém o nome da unidade com o .d anexado. Por exemplo, para o nginx.service, um diretório chamado nginx.service.d será criado.

      Dentro deste diretório, um trecho de código chamado override.conf será criado. Quando a unidade for carregada, o systemd irá mesclar, na memória, o trecho sobrescrito com o arquivo de unidade completo. As diretivas do trecho terão precedência sobre aquelas encontradas no arquivo de unidade original.

      Se quiser editar o arquivo de unidade completo ao invés de criar um fragmento, passe o sinalizador --full:

      • sudo systemctl edit --full nginx.service

      Isso irá carregar o arquivo de unidade atual no editor, onde pode ser modificado. Quando o editor for fechado, o arquivo alterado será escrito em /etc/systemd/system e terá precedência sobre a definição de unidade do sistema (geralmente encontrada em algum lugar em /lib/systemd/system).

      Para remover qualquer adição que tenha sido feita, exclua o diretório de configuração .d da unidade ou o arquivo de serviço modificado de /etc/systemd/system. Por exemplo, para remover um fragmento, podemos digitar:

      • sudo rm -r /etc/systemd/system/nginx.service.d

      Para remover um arquivo de unidade modificado completo, digitamos:

      • sudo rm /etc/systemd/system/nginx.service

      Depois de excluir o arquivo ou diretório, recarregue o processo do systemd para que ele não tente mais fazer referência a esses arquivos e volte a usar as cópias do sistema. Faça isso digitando:

      • sudo systemctl daemon-reload

      Os alvos são arquivos de unidade especiais que descrevem um estado do sistema ou um ponto de sincronização. Assim como outras unidades, os arquivos que definem alvos podem ser identificados por seu sufixo, que neste caso é .target. Os alvos não fazem muito por conta própria, mas são usados para agrupar outras unidades.

      Isso pode ser usado para trazer o sistema para determinados estados, da mesma forma que outros sistemas init usam os níveis de execução. Eles são usados como referência para quando certas funções estão disponíveis, permitindo especificar o estado desejado em vez das unidades individuais necessárias para produzir esse estado.

      Por exemplo, existe um swap.target que é usado para indicar que o swap está pronto para ser usado. Unidades que fazem parte deste processo podem sincronizar-se com esse alvo indicando em sua configuração que elas são WantedBy= ou RequiredBy= pelo swap.target. Unidades que exigem o swap para ficarem disponíveis podem especificar essa condição usando as especificações Wants=, Requires= e After= para indicar a natureza do seu relacionamento.

      Obtendo e definindo o alvo padrão

      O processo do systemd possui um alvo padrão usado por ele ao inicializar o sistema. Satisfazer a cascata de dependências a partir desse único alvo irá trazer o sistema para o estado desejado. Para encontrar o alvo padrão para o seu sistema, digite:

      Output

      multi-user.target

      Se quiser definir um alvo padrão diferente, use o set-default. Por exemplo, se você possui um desktop gráfico instalado e quer que o sistema seja inicializado nele por padrão, altere seu alvo padrão de acordo:

      • sudo systemctl set-default graphical.target

      Listando alvos disponíveis

      É possível obter uma lista dos alvos disponíveis em seu sistema digitando:

      • systemctl list-unit-files --type=target

      Ao contrário dos níveis de execução, vários alvos podem estar ativos ao mesmo tempo. Um alvo ativo indica que o systemd tentou iniciar todas as unidades ligadas ao alvo e não tentou destruí-las novamente. Para ver todos os alvos ativos, digite:

      • systemctl list-units --type=target

      Isolando alvos

      É possível iniciar todas as unidades associadas a um alvo e parar todas as unidades que não fazem parte da árvore de dependência. O comando que precisamos emitir para isso chama-se, apropriadamente, isolate. Isso é parecido com alterar o nível de execução em outros sistemas init.

      Por exemplo, se estiver operando em um ambiente gráfico com o graphical.target ativo, você pode desligar o sistema gráfico e colocar o sistema em um estado de linha de comando multiusuário isolando o multi-user.target. Como o graphical.target depende do multi-user.target, mas o contrário não é válido, todas as unidades gráficas serão interrompidas.

      Pode ser interessante dar uma olhada nas dependências do alvo que você está isolando antes de executar este procedimento, de forma a garantir que não estará impedindo serviços vitais:

      • systemctl list-dependencies multi-user.target

      Quando estiver satisfeito com as unidades que serão mantidas vivas, isole o alvo digitando:

      • sudo systemctl isolate multi-user.target

      Usando atalhos para eventos importantes

      Existem alvos definidos para eventos importantes, como desligar ou reinicializar o sistema. No entanto, o systemctl também possui alguns atalhos que adicionam outras funcionalidades adicionais.

      Por exemplo, para colocar o sistema em modo de resgate (único usuário), simplesmente use o comando rescue ao invés de isolate rescue.target:

      Isso irá fornecer a funcionalidade adicional de alertar todos os usuários conectados sobre o evento.

      Para parar o sistema, use o comando halt:

      Para iniciar um desligamento completo, use o comando poweroff:

      Uma reinicialização pode ser feita com o comando reboot:

      Todos esses comandos alertam usuários conectados que o evento está ocorrendo, o que não acontece ao apenas executar ou isolar o alvo. Observe que a maioria das máquinas irão vincular os comandos mais curtos e convencionais para essas operações de modo que funcionem corretamente com o systemd.

      Por exemplo, para reiniciar o sistema, costuma-se digitar:

      Conclusão

      A partir agora, você deve estar familiarizado com algumas das capacidades básicas do comando systemctl que permitem interagir e controlar sua instância do systemd. O utilitário systemctl será o seu ponto principal de interação para o gerenciamento do serviço e do estado do sistema.

      Embora o systemctl opere principalmente com o processo principal do systemd, existem outros componentes do ecossistema do systemd que são controlados por outros utilitários. Outras capacidades, como o gerenciamento de registro e sessões de usuário são controladas por daemons e utilitários de gerenciamento separados (journald/journalctl e logind/loginctl respectivamente). Gastar algum tempo para se familiarizar com essas outras ferramentas e daemons irá tornar o gerenciamento uma tarefa mais fácil.



      Source link

      Cómo agregar prueba de unidades a su proyecto de Django


      El autor seleccionó a Open Internet/Free Speech Fund para recibir una donación como parte del programa Write for DOnations.

      Introducción

      Es casi imposible crear sitios web que desde el principio funcionen a la perfección y no tengan errores. Por ese motivo, debe probar su aplicación web para encontrar esos errores y trabajar en ellos de forma proactiva. Para mejorar la eficiencia de las pruebas, es común desglosarlas en unidades que prueben funcionalidades específicas de la aplicación web. Esta práctica se denomina prueba de unidades. Hace que sea más fácil detectar errores, dado que las pruebas se centran en pequeñas partes (unidades) de su proyecto independientemente de otras.

      Probar un sitio web puede ser una tarea compleja, ya que consta de varias capas de lógica, como la gestión de solicitudes HTTP, la validación de formularios y la representación de plantillas. Sin embargo, Django ofrece un conjunto de herramientas que le permite probar su aplicación web sin problemas. Aunque es posible utilizar otros marcos de pruebas, la opción preferida para escribir pruebas en Django es usar el módulo unittest de Python.

      A través de este tutorial, configurará un conjunto de pruebas en su proyecto de Django y escribirá pruebas de unidades para los modelos y vistas de su aplicación. Ejecutará estas pruebas, analizará sus resultados y aprenderá a encontrar las causas de errores en las pruebas que fallan.

      Requisitos previos

      Antes de iniciar este tutorial, necesitará lo siguiente:

      Paso 1: Agregar un conjunto de pruebas a su aplicación en Django

      Un conjunto de pruebas en Django es una colección de todos los casos de prueba en todas las aplicaciones de su proyecto. Para lograr que la utilidad de prueba de Django descubra los casos de prueba que tiene, se escriben los casos de prueba en secuencias de comandos cuyos nombres comiencen con test. En este paso, creará la estructura del directorio y los archivos para su conjunto de pruebas, y creará un caso de prueba vacío dentro de él.

      Si siguió la serie de tutoriales Desarrollo en Django, tendrá una aplicación de Django denominada blogsite.

      Crearemos una carpeta para contener todos nuestros scripts de prueba. Primero, active el entorno virtual:

      • cd ~/my_blog_app
      • . env/bin/activate

      Luego, diríjase al directorio de la aplicación blogsite, la carpeta que contiene los archivos models.py y views.py, y luego cree una carpeta nueva llamada tests:

      • cd ~/my_blog_app/blog/blogsite
      • mkdir tests

      A continuación, convertirá esta carpeta en un paquete Python; agregue un archivo __init__.py:

      • cd ~/my_blog_app/blog/blogsite/tests
      • touch __init__.py

      Ahora, agregue un archivo para probar sus modelos y otro para probar sus vistas:

      • touch test_models.py
      • touch test_views.py

      Por último, creará un caso de prueba vacío en test_models.py. Deberá importar la clase TestCase de Django y hacer que sea una súper clase de su propia clase de caso de prueba. Más adelante, añadirá métodos a este caso de prueba para probar la lógica en sus modelos. Abra el archivo test_models.py​​​1​​​:

      Luego, añada el siguiente código al archivo:

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      
      class ModelsTestCase(TestCase):
          pass
      

      De esta manera, habrá añadido correctamente un conjunto de pruebas a la aplicación blogsite. Luego, completará los detalles del caso de prueba de modelo vacío que creó aquí.

      Paso 2: Probar su código Python

      En este paso, probará la lógica del código escrito en el archivo models.py. En particular, probará el método save del modelo Post para asegurarse de que cree el slug correcto del título de una entrada cuando se invoque.

      En este caso, comenzaremos observando el código que ya tiene en su archivo models.py para ver el método save del modelo Post:

      • cd ~/my_blog_app/blog/blogsite
      • nano models.py

      Observará lo siguiente:

      ~/my_blog_app/blog/blogsite/models.py

      class Post(models.Model):
          ...
          def save(self, *args, **kwargs):
              if not self.slug:
                  self.slug = slugify(self.title)
              super(Post, self).save(*args, **kwargs)
          ...
      

      Podemos ver que verifica si la entrada que está a punto de guardar tiene un valor slug, y, si no, invoca a slugify a fin de crear un valor slug para la misma. Este es el tipo de lógica que tal vez quiera probar para asegurarse de que los slugs se creen en realidad cuando se guarde una entrada.

      Cierre el archivo.

      Para probar esto, regrese a test_models.py:

      Luego, actualícelo para que se vea como a continuación y agregue las porciones resaltadas:

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      from django.template.defaultfilters import slugify
      from blogsite.models import Post
      
      
      class ModelsTestCase(TestCase):
          def test_post_has_slug(self):
              """Posts are given slugs correctly when saving"""
              post = Post.objects.create(title="My first post")
      
              post.author = "John Doe"
              post.save()
              self.assertEqual(post.slug, slugify(post.title))
      

      Este nuevo método test_post_has_slug crea una nueva entrada con el título "My first post" y, luego, atribuye a esta un autor y la guarda. Después de esto, usando el método assertEqual del módulo unittest de Python, se comprueba si el slug de la entrada es correcto. El método assertEqual verifica si los dos argumentos que se le pasan son iguales, como lo determina el operador "==", y genera un error si no lo son.

      Guarde y cierre test_models.py.

      Este es un ejemplo de lo que se puede probar. Cuanta más lógica añada a su proyecto, habrá más por probar. Si añade más lógica al método save o crea nuevos métodos para el modelo Post, querrá añadir más pruebas aquí. Usted puede añadirlas al método test_post_has_slug o crear nuevos métodos de prueba, pero sus nombres deben comenzar con test.

      Creó con éxito un caso de prueba para el modelo Post, en el que validó que los slugs se crean correctamente después del guardado. En el siguiente paso, escribirá un caso de prueba para probar las vistas.

      Paso 3: Usar el cliente de prueba de Django

      En este paso, escribirá un caso de prueba que probará una vista utilizando el cliente de prueba de Django. El cliente de prueba es una clase de Python que funciona como navegador web ficticio, le permite probar sus vistas e interactuar con su aplicación Django como un usuario lo haría. Puede acceder al cliente de prueba haciendo referencia a self.client en sus métodos de prueba. Por ejemplo, crearemos un caso de prueba en test_views.py. Primero, abra el archivo test_views.py:

      Luego, agregue lo siguiente:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 200)
      

      El ViewsTestCase contiene un método test_index_loads_properly que utiliza el cliente de prueba de Django para visitar la página principal del sitio web (http://your_server_ip:8000, donde your_server_ip es la dirección IP del servidor que utiliza). Luego, el método de prueba comprueba si la respuesta tiene un código de estado 200, lo cual significa que la página respondió sin errores. Como resultado, puede estar seguro de que cuando el usuario visite la página también responderá sin errores.

      Además del código de estado, puede leer sobre otras propiedades de la respuesta del cliente de prueba que puede probar en la página de documentación de respuestas de prueba de Django.

      En este paso, creó un caso de prueba para probar la vista que genera la página principal y verificar que funcione sin errores. Ahora, hay dos casos de prueba en su conjunto de pruebas. En el siguiente paso, los ejecutará para ver sus resultados.

      Paso 4: Ejecutar sus pruebas

      Ahora que terminó de crear un conjunto de pruebas para el proyecto, es el momento de ejecutar estas pruebas y ver sus resultados. Para ejecutar las pruebas, diríjase a la carpeta blog (que contiene el archivo manage.py de la aplicación):

      Luego, ejecútelas con lo siguiente:

      Verá un resultado similar al siguiente en su terminal:

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .. ---------------------------------------------------------------------- Ran 2 tests in 0.007s OK Destroying test database for alias 'default'...

      En este resultado, hay dos puntos .., cada uno de los cuales representa un caso de prueba aprobado. Ahora, modificará test_views.py para activar una prueba que falle. Abra el archivo con lo siguiente:

      Luego, cambie el código resaltado para ver lo siguiente:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      Aquí, cambió el código de estado de 200 a 404. Ahora, ejecute la prueba de nuevo desde su directorio con manage.py:

      Verá el siguiente resultado:

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .F ====================================================================== FAIL: test_index_loads_properly (blogsite.tests.test_views.ViewsTestCase) The index page loads properly ---------------------------------------------------------------------- Traceback (most recent call last): File "~/my_blog_app/blog/blogsite/tests/test_views.py", line 8, in test_index_loads_properly self.assertEqual(response.status_code, 404) AssertionError: 200 != 404 ---------------------------------------------------------------------- Ran 2 tests in 0.007s FAILED (failures=1) Destroying test database for alias 'default'...

      Verá aparecer un mensaje de error descriptivo en el que se indicará la secuencia de comandos, el caso de prueba y el método que falló. También se mostrará la causa de la falla, con un código de estado que no es igual al 404 en este caso, con el mensaje AssertionError: 200 ! = 404. El AssertionError aquí se genera en la línea de código resaltada en el archivo test_views.py:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      Le indica que la afirmación es falsa, es decir, el código de estado de respuesta (200) no es lo que se esperaba (404). Precediendo el mensaje de error, puede ver que los dos puntos .. pasaron a ser . F, lo cual indica que el primer caso de prueba se aprobó mientras que el segundo no.

      Conclusión

      A través de este tutorial, creó un conjunto de pruebas en su proyecto de Django, añadió casos de prueba para probar el modelo y la lógica de visualización, aprendió a ejecutar pruebas y analizó el resultado de una prueba. Como siguiente paso, puede crear nuevas secuencias de comandos para código Python que no estén en models.py y views.py.

      A continuación, consulte algunos artículos que pueden ser útiles al crear y probar sitios web con Django:

      También puede consultar nuestra página de temas de Django para ver tutoriales y proyectos adicionales.



      Source link