Recetas·Ubuntu·VSCode

Usando vscode-chrome-debug como extensión de workspace

Visual_Studio_code_logo-274x300

Escenario:

  • VSCode con las extensiones de Remote Development instaladas.
  • Desarrollo en contenedores Docker.
  • Imagen Docker con chrome instalado.
  • Chrome no instalado en la máquina host.
  • Queremos utilizar el chrome del contenedor Docker para depurar nuestras aplicaciones.

Guía paso a paso:

  • Utilizar un Dockerfile basado en una imagen con chrome instalado (en mi caso, utilizo una imagen basada en Ubuntu 18.04 y personalizada para mis necesidades de desarrollo)

    FROM rubensa/ubuntu-tini-dev-chrome
    # Keep container running (for use in VSCode)
    CMD [ “tail”, “-f”, “/dev/null” ]
  • En el fichero devcontainer.json añadir la extensión Debugger for Chrome y forzarla para se se ejecute en “workspace” (en vez de en “ui“)
    {
      ...
      "extensions": [
        // Chrome debugger
        "msjsdiag.debugger-for-chrome"
      ],
      "settings": {
        "remote.extensionKind": {
          // Force chrome debugger extension installation on container
          "msjsdiag.debugger-for-chrome": [
            "workspace"
          ]
        }
      },
      ...
    }

    NOTA: para que esto funciona, también es necesario instalar la extensión localmente (pero manteniéndola deshabilitada Locally y habilitada en Dev Container)

  • Configurar los siguientes argumentos Docker dentro del fichero devcontainer.json
    {
      ...
      "runArgs": [
        // X11 Unix-domain socket
        "--mount",
        "type=bind,source=/tmp/.X11-unix,target=/tmp/.X11-unix",
        "--env=DISPLAY=unix${localEnv:DISPLAY}",
        // Allow shared memory to avoid RAM access failures and rendering glitches due to X extesnion MIT-SHM
        "--ipc=host",
        // The kernel requires SYS_ADMIN for Chrome sand-box
        "--cap-add",
        "SYS_ADMIN",
        // $(id -u):$(id -g)
        "-u",
        "1000:1000"
      ],
      ...
    }
    

    En mi Dockerfile particular debo especificar en devcontainer.json que VSCode no sobreescriba el comando por defecto de mi imagen.

    {
      ...
      "overrideCommand": false
      ...
    }
    

Ahora, al abrir tu proyecto en Remote – Containers, podrás depurar el código dentro del contenedor.

Recetas·VSCode

VSCode Live Share login manual

vscode-liveshare-logo

  • Haz login usando cualquier cuenta en la página: https://prod.liveshare.vsengsaas.visualstudio.com/auth/login
    Screenshot from 2020-02-19 16-54-21
  • Tras el flujo de autentificación se te redirecciona a la página “Ready to collaborate
    Screenshot from 2020-02-19 16-55-38
  • Pulsa en el enlace “Having trouble? Click here for user code directions
    Screenshot from 2020-02-19 16-56-26
  • Abre la paleta de comandos del VSCode y escribe > live share: Sign in with user code
    Screenshot from 2020-02-19 17-00-47
  • Pega el código de usuario que has copiado del navegador.

NOTA: El código de usuario solamente es válido durante 2 minutos (comenzando desde que se te muestra la página “Ready to collaborate”)

Docker·Ubuntu

Docker no usa los mismos DNS que el host

Docker_(container_engine)_logo

Docker rellena el fichero /etc/resolv.conf de los contenedores copiando el /etc/resolv.conf del host y filtrando cualquier servidor de nombres local como podría ser 127.0.0.53.  Si no hay ningún otro servidor de nombres, Docker añadirá los servidores DNS públicos de Google (8.8.8.8 y 8.8.4.4)

En Ubuntu 18.04, y otros sistemas que usan systemd-resolved, /etc/resolv.conf es un enlace a /run/systemd/resolve/stub-resolv.conf y su contenido siempre tiene la ip local 127.0.0.53:

nameserver 127.0.0.53
options edns0

y, como hemos explicado antes, Docker filtra cualquier dirección de loopback al leer el resolv.conf. Por tanto, nuestros contenedores Docker no usaran los DNS que utiliza el host, sino que siempre usará los DNS de Google.

Para solucionar esto, vamos a “tomar control” del fichero /etc/resolv.conf y a realizar las configuraciones necesarias para que los contenedores acaben usando la configuración de DNS del host.

La idea es sencilla.

  1. En /etc/resolv.conf seguiremos referenciando como primer dns el 127.0.0.53 (que sabemos que Docker eliminará)
  2. Además añadimos una nueva entrada referenciando al propio host (para que los contenedores Docker usen el host como servidor DNS)

Sigue leyendo “Docker no usa los mismos DNS que el host”

Angular·Ubuntu

Port forwarding en VSCode Remote Development

remote-extensionpack

Trabajando en un proyecto en Angular usando la extensión de desarrollo remoto que VSCode tiene para poder desarrollar dentro de un contenedor Docker, me encontré con un extraño comportamiento:

Al arrancar el servidor de desarrollo de Angular mediante ng serve, en la consola del VSCode se me mostraba el típico mensaje con el enlace para abrir la aplicación en el navegador.

** Angular Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200/ **

Lo curioso del caso es que al pulsar (Ctrl+Click) en dicho enlace se me habría el navegador en la URL http://127.0.0.1:40999/ en vez de http://localhost:4200/.  Es más, si intentaba acceder a http://localhost:4200/ no podía acceder a la aplicación. 

Y todo esto, habiendo publicado el puerto en el fichero devcontainer.json


...
"appPort": [
// Front-end development (Angular server)
"0.0.0.0:4200:4200"
],
...

Sigue leyendo “Port forwarding en VSCode Remote Development”

GIT·Recetas·VCS

Limpieza de ramas locales tras el merge y borrado en el servidor central

git

Si utilizas Github o Gitlab, seguramente estará familiarizado en los Pull Requests o Merge Requests. Ambos tienen una opción para eliminar una rama tras hacer el merge del Pull/Merge Request.

El problema es que dicha opción solamente borrará la rama en el repositorio remoto. Ahora bien, cómo podemos “limpiar” nuestras ramas locales?

Supongamos que tenemos la rama “feature

    1. Listado de ramas en el equipo local
      El comando git branch -a muestra que la rama “feature” existe en local pero también muestra la referencia a la rama remota inexistente.

      $ git branch -a
      feature
      * master
      remotes/origin/master
      remotes/origin/feature
    2. Limpieza” de las referencias locales a las rama remotas
      El comando git remote prune origin --dry-run hace una “simulación” (--dry-run) de “limpieza” de ramas remotas (porque ya no existen en el servidor remoto).

      $ git remote prune origin --dry-run
      Pruning origin
      URL: git@github.com:rubensa/repo.git
      * [would prune] origin/feature

      Una vez comprobado que todo es correcto, podemos proceder a ejecutar realmente el comando de borrado.

      $ git remote prune origin
      Pruning origin
      URL: git@github.com:rubensa/repo.git
      * [pruned] origin/feature

      Una vez mas, ejecutando el comando git branch -a se nos mostrará el estado local de las ramas.

      $ git branch -a
      feature
      * master
      remotes/origin/master

      Podemos ver que remotes/origin/feature ha sido eliminada, pero no así la rama local feature.

    3. Eliminación de rama local
      Si queremos, también podemos “limpiar” la rama local feature:

      $ git branch -d
      Deleted branch feature (was 6493f15).

       

vía

Recetas·Ubuntu

Usando dig para consultar un servidor DN específico

dns

Hay ocasiones en la que puedes necesitar consultar un servidor DNS directamente. Por ejemplo, antes de cambiar los servidores DNS de un dominio, puedes configurar los nuevos registros en los nuevos servidores DNS y entonces consultarlos directamente para asegurarte de que tienen los registros correctos.

dig te permite especificar un servidor de nombres junto con el registro que quieres consultar.

Por ejemplo, uno de los servidores DNS de rubensa.eu.org es “freedns1.registrar-servers.com“. Podemos consultar en este servidor directamente el registro www mediante:

$ dig rubensa.eu.org @freedns1.registrar-servers.com

Lo que nos dará una salida con una sección de título Answer Section:

;; ANSWER SECTION:
rubensa.eu.org. 1800 IN A 185.199.109.153
rubensa.eu.org. 1800 IN A 185.199.108.153

En ella se detalla el resultado (185.199.109.153) así como el TTL del registro (en segundos). El TTL es importante, ya que indica el tiempo que los servidores DNS pueden cachear el resultado.

Puedes hacer lo mismo para comprobar otros registros como, por ejemplo, los registros MX, simplemente añadiendo el tipo de registro al comando. Por ejemplo:

$ dig MX rubensa.eu.org @freedns1.registrar-servers.com

devolverá:

;; ANSWER SECTION:
rubensa.eu.org. 1800 IN MX 20 mx2.zoho.com.
rubensa.eu.org. 1800 IN MX 10 mx.zoho.com.
rubensa.eu.org. 1800 IN MX 50 mx3.zoho.com.

Aquí podemos ver que el TTL es de 1800 segundo (30 minutos) y que el nivel de prioridad de servidor va de mx.zoho.com a mx3.zoho.com.

vía

Recetas·Ubuntu

Tooltips en negro en Gnome 3

gnome-logo-icon

Al ejecutar aplicaciones gráficas en docker, me he encontrado con problemas con los tooltips de las mismas, de modo que era imposible verlos ya que solamente aparecía un cuadro totalmente en negro.

La solución pasa por personalizar los colores del theme de Gnome 3 de mi host (Ubuntu 19.10).

Para hacer esto, basta con crear el fichero ~/.config/gtk-3.0/gtk.css con el siguiente contenido:

@define-color base_color #ffffff;
@define-color tooltip_bg_color #00ff00;
@define-color tooltip_fg_color #ff0000;
@define-color theme_tooltip_bg_color @tooltip_bg_color;
@define-color theme_tooltip_fg_color @tooltip_fg_color;

tooltip {
  padding: 5px 5px 5px 5px;
  margin: 0px 0px 0px 0px;
    border-width: 1px;
    border-style: solid;
    border-radius: 0px;
    border-color: #ffffff;
    background-image: none;
    background-color: #ffffff;
    color: #454545;
    border: 0px;
}

tooltip * {
    background-color: #ffffff;
    font-weight: bold;
    padding: 5px 5px 5px 5px;
    margin: 0px 0px 0px 0px;
    border-width: 1px;
    border-style: solid;
    border-color: @tooltip_bg_color;
    color: #454545;
    text-shadow: 5px 5px 3px #bbbbbb, 7px 7px 3px #ccccFF;
}

vía