williamkborn

Is ChatGPT Using Containers to Aid Code Analysis?

I was recently playing around with some of the ChatGPT text adventure simulations to show a friend what ChatGPT was capable of. We started to mess around with a "shell" simulation, very similar to this article:

https://arstechnica.com/information-technology/2022/12/openais-new-chatbot-can-hallucinate-a-linux-shell-or-calling-a-bbs/

This article asserts that the "shell" that ChatGPT is producing is a mere hallucination:

ChatGPT can simulate a Linux machine because enough information about how a Linux machine should behave was included in its training data. That data likely includes software documentation (like manual pages), troubleshooting posts on Internet forums, and logged output from shell sessions.

BrutalSimplicity

FROM debian:latest

# Install basic dev packages
RUN apt-get clean && apt-get update && apt-get -y install --no-install-recommends \
    apt-utils \
    openssh-client \
    git \
    gnupg2 \
    dirmngr \
    iproute2 \

mikesparr

Architecting for the cloud

• Architect solutions to be scalable and reilient
• Business requirements involve lowering costs / enhancing user experience
• Keep an eye on technical needs during development and operation

---

3 Major Questions To Ask

1. Where is the company coming from

JosefJezek

To convert animation GIF to MP4 by ffmpeg, use the following command

ffmpeg -i animated.gif -movflags faststart -pix_fmt yuv420p -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" video.mp4

Description

movflags – This option optimizes the structure of the MP4 file so the browser can load it as quickly as possible.

pix_fmt – MP4 videos store pixels in different formats. We include this option to specify a specific format which has maximum compatibility across all browsers.

mikesparr

#!/usr/bin/env bash

# [1] https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent#add_configmap
# [2] https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent#config_agent_configmap
# [3] https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent#create_manual

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_USER=$(gcloud config get-value core/account) # set current user
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")
export IDNS=${PROJECT_ID}.svc.id.goog # workflow identity domain

mikesparr

#!/usr/bin/env bash

# REF: https://cloud.google.com/armor/docs/integrating-cloud-armor#with_ingress 
# REF: https://cloud.google.com/armor/docs/configure-security-policies
# REF: https://cloud.google.com/iap/docs/load-balancer-howto 
# REF: https://cloud.google.com/sdk/gcloud/reference/compute/url-maps/add-path-matcher 
# REF: https://cloud.google.com/load-balancing/docs/https/setting-up-url-rewrite

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_USER=$(gcloud config get-value core/account) # set current user

jimangel

Fixes errors in Kubernetes v1.22+:

• kubelet cgroup driver: \"cgroupfs\" is different from docker cgroup driver: \"systemd\""
• kubelet cgroup driver: \"systemd\" is different from docker cgroup driver: \"cgroupfs\""

By setting both to use systemd as preferred by kubeadm.

Kubeadm: remove the automatic detection and matching of cgroup drivers for Docker. For new clusters if you have not configured the cgroup driver explicitly you might get a failure in the kubelet on driver mismatch (kubeadm clusters should be using the systemd driver). Also remove the IsDockerSystemdCheck preflight check (warning) that checks if the Docker cgroup driver is set to systemd. Ideally such detection / coordination should be on the side of CRI implementers and the kubelet. Please see the page on [how to configure cgroup drivers](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/

pmbaumgartner

#cloud-config
package_upgrade: true

ssh_authorized_keys:
  - <your key>

packages:
  - apt-transport-https
  - ca-certificates
  - curl

ramkicse

multipass launch -c 15 -m 20G -d 100G -n master --cloud-init cloud-init.yaml

multipass launch -c 15 -m 20G -d 100G -n worker1 --cloud-init cloud-init.yaml

multipass launch -c 15 -m 20G -d 100G -n worker2 --cloud-init cloud-init.yaml

multipass launch -c 15 -m 20G -d 100G -n worker3 --cloud-init cloud-init.yaml

multipass launch -c 15 -m 20G -d 100G -n worker4 --cloud-init cloud-init.yaml

mikesparr

SRE best practices

• don’t expect a tool to solve
• cultural change and need “believers” in senior role to advocate within company
• people need to absorb info within their own mindset

“Reliability is a journey”

• it is a process that can span 6-9 months in orgs w/ 5000 engineers; nothing happens immediately
• Step 1: “I want to be reliable when I grow up” (you must believe you have problem first)
• Step 2: “Read the book!” and watch SRE v DevOps
• Step 3: “Panic!” (myth: fire team and retrain; not the case and can retrain team in house)