Archivo de la categoría: Linux

Azure Cloud Shell ya está aqui!


La pasada semana apareció la funcionalidad de Azure Cloud Shell en disponibilidad general en la Microsoft’s Build Conference  …. y ¿que es?¿cómo funciona?¿qué puedo hacer con ella? Os dejo unas pinceladas de todo su potencial, el resto ….. hay que descubrirlo 😉

Azure Cloud Shell nos ofrece una experiencia de Shell preconfigurada, accesible desde el navegador, para gestionar los recursos de Azure sin la sobrecarga que nos supone la instalación, versionado y mantenimiento de un servidor dedicado para este fin, sin olvidarnos de una gran variedad de herramientas directamente desde nuestro navegador favorito a través del Portal de Azure.

Hay que tener en cuenta que Cloud Shell se autentica en cada sesión que abramos a través de Azure CLI 2.0

Otros puntos a tener en cuenta son:

  • Cloud Shell  se ejecuta en una máquina temporal que se proporciona por sesión y por usuario.
  • Cloud Shell se cerrará despues de tener 10 minutos de inactividad.
  • Cloud Shell solo puede ser accedida a través de un recurso compartido.
  • Los permisos se establecen como un usuario normal de Linux.

Ademas, estas son las Herramientas y características incluidas:

  • Interpretes de Shell de Linux.-
    • Bash
    • SH
  • Control de fuentes.-
    • Git
  • Containers.-
    • Docker
    • Kubectl
    • DC/OS CLI
  • Bases de datos
    • PostgreSql client
    • MySQL client
    • sqlcmd Utility
  • Herramientas de Azure.-
    • Azure CLI 2.0
    • Azure CLI 1.0
  • Editores de texto:
    • vim
    • nano
    • emacs

Y, lo que parece una primicia … Azure Powershell 3.0, la caña!!!

Como las máquinas que se utilizan para Cloud Shell son temporales se requieren que se instale un “Recurso Compartido” para ser montado de manera persistente el directorio $Home.

Cuando lo configuramos/abrimos por primera vez, Cloud Shell nos solicita la creación de un Grupo de Recursos, una cuenta de almacenamiento y un recurso compartido

Esta cuenta de almacenamiento es LRS, las tres réplicas locales de rigor. El Recurso Compartido es un Azure Files de 5GB.

Este paso solo ocurrirá la primera vez, luego ….. coser y cantar!!!

Y para terminar …

Listos para empezar.

Que tengais buena semana.

Anuncios

Problema de inodos llenos en Linux en Azure.


Buenos dias a todos,

Ya sabeis que Microsoft ama Linux, las Open Sources, etc., Y mas si se pueden desplegar desde Azure 😉 . Yo si que amo a Azure. Que pasada.

Últimamente he tenido que tratar con problemas sobre servicios que corren en diferentes versiones de Linux que podemos desplegar en Azure (ver aqui), CentOS, Debian, Ubuntu, SUSE, Redhat, etc….

Hoy, último dia de noviembre, me centro en un extraño problema del que solo tenía la siguiente evidencia: En mi servidor web me aparecian errores del tipo “no space left on device” , “write failed” “user block limit reached”.  Detalle extraño ya que, el disco es de 1TB y comprobándolo, tenía la siguiente la información:

S.ficheros Bloques de 1K Usado Disponible Uso% Montado en
/dev/md/1 10403064 3252248 6626532 33%
udev 4035092 208 4034884 1% /dev
/dev/md/2 958137332 49863180 859986824 6% /home
shm 4035092 0 4035092 0% /dev/shm

Como podeis ver,  ejecutando el comando df  pude observar que tan solo tenía ocupado un 33%. ¿Por qué me aparecian esos errores de espacio y limitaciones?

Aqui es donde viene la labor de “detective” (jejejeje, es broma) y buscando errores similares encontré que el fallo se produjo por una saturación de i-nodos ,

¿Qué son los inodos? pues son estructuras de datos empleados en sistemas Linux y Unix que contienen información sobre los ficheros. Os habeis quedado igual ¿verdad? Quedemonos con el concepto de que cada fichero se identifica por un número de inodo. Este número es único dentro de todo el sistema de ficheros. De todas maneras, aqui os dejo unos links:

Echemos un vistazo a ver cómo están nuestros inodos. Ejecutamos  df -i

S.ficheros Nodos-i NUsados NLibres NUso% Montado en
/dev/md/1 655360 655360 0 100% /
udev 1008773 5418 1003355 1% /dev
/dev/md/2 60366848 910175 59456673 2% /home
shm 1008773 1 1008772 1% /dev/shm

Here we go!!! Aqui está el problema. Normalmene esto ocurre por la creación de infinidad de ficheros pequeños dentro de un directorio, en el caso de mi servidor web, estaba claro que era en en la partición montada en el raíz /.

Y ¿Cómo encontrar dónde se encuentran dichos ficheros?En este caso ejecutamos el siguiente comando:

find . -printf “%in” | sort -u | wc -l

De esta forma obtendremos el número de ficheros de cada directorio, empezando por el raiz y, posteriormente, en los subdirectorios, hasta encontrar la ruta d

e los mil y un ficheros pequeños: /opt/bitnami/apps/wordpress/tmp. Ah!!!!! mi WordPress. Ah!!!! el repositorio Bitnami con IaaS desplegadas y configuradas por defecto!!!!!

Bien, para corregir este problema, creamos una tarea en el crontab del usuario root para que se ejecute todos los días a las 00:01, que busque y elimine ficheros más antiguos de 30 días en la ruta /opt/bitnami/apps/wordpress/tmp .

root@vmwebsrvwp01:~# crontab -l|grep -v #

01 00 * * * /root/remove-tmp-bitnami.files.ksh > /root/remove-tmp-bitnami.files.LOG 2>&1

el hecho de buscar y encontrar un post de @jabenitezdev, con un problema idéntico al mio, escrito en su blog, me centró el problema y, sobre todo, en la resolución, muchas gracias por compartir 😉

Agradecer y dedicar este post a mis antiguos compañeros de Capgemini, David, Alex, Ivan, Beatriz, Angel, Jose Luis, Christian, etc. Muy buenos momentos y muy buena gente. Espero veros pronto.

Besos y abrazos.

masrobeznoquenunca

Comparto lo que hago y lo que veo.

El camino de un ITPro

El camino de un ITPro

adumont

Just another WordPress.com weblog

Marco Antonio's space

Una mirada dentro de mis ratos libres...

Marcelo Ruiz

Network and SocialMedia

A Digital Frontier...

Blog personal de Robert Garrandés Simancas ("Versión Beta")

enero11

Literatura para romper el tiempo.

A %d blogueros les gusta esto: