Jenkins Pipeline - set and use environment variables

Jenkins Pipeline - set and use environment variables

How to list the environment variables available to Jenkins Pipeline examples/jenkins/list_environment.Jenkinsfile pipeline { agent none environment { color = "blue" } stages { stage('first') { agent { label 'master' } steps { sh "printenv | sort" } } } }   In this example we list the environment variables using the printenv command of Unix/Linux which we pipe through the Unix sort command so we'll see the environment variables in a sorted list. We invoke it using the sh command of the Jenkins Pipeline. Before we do that we set a new variable called "color" in the environment section of the Jenkins Pipeline. On Unix/Linux: sh('printenv | sort') On Windows you could run: bat('set') The output will looks something like this: BUILD_DISPLAY_NAME=#18 BUILD_ID=18 BUILD_NUMBER=18 BUILD_TAG=jenkins-list_environment_variables-18 BUILD_URL=http://localhost:8080/job/list_environment_variables/18/ DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/110/bus EXECUTOR_NUMBER=1 HOME=/var/lib/jenkins HUDSON_COOKIE=40cd788e-91bd-4ebd-86c9-c10333fa27a9 HUDSON_HOME=/var/lib/jenkins HUDSON_SERVER_COOKIE=912830efeb6e2316 HUDSON_URL=http://localhost:8080/ JENKINS_HOME=/var/lib/jenkins JENKINS_NODE_COOKIE=dbf878e6-0ae5-4ffe-a32c-aa7876f975ce JENKINS_SERVER_COOKIE=durable-f6e3ca8e5d2310d4d5695d128db1ea2f JENKINS_URL=http://localhost:8080/ JOB_BASE_NAME=list_environment_variables JOB_DISPLAY_URL=http://localhost:8080/job/list_environment_variables/display/redirect JOB_NAME=list_environment_variables JOB_URL=http://localhost:8080/job/list_environment_variables/ LANG=C.UTF-8 LOGNAME=jenkins MAIL=/var/mail/jenkins NODE_LABELS=master NODE_NAME=master PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin PWD=/var/lib/jenkins/workspace/list_environment_variables RUN_CHANGES_DISPLAY_URL=http://localhost:8080/job/list_environment_variables/18/display/redirect?page=changes RUN_DISPLAY_URL=http://local

【HTTP】GET传参最大长度的理解误区

【HTTP】GET传参最大长度的理解误区

零、总结 文章数据来源于网络,可能存在变动,但是原理是一样的。 HTTP 协议 未规定 GET 和POST的长度限制 GET的最大长度显示是因为 浏览器和 web服务器限制了 URI的长度 不同的浏览器和WEB服务器,限制的最大长度不一样 要支持IE,则最大长度为2083byte,若只支持Chrome,则最大长度 8182byte 一、误解 大家都知道http 中 存在 GET 和 POST 这两种最常用的请求方式。(PUT,DELETE不在本文讨论范围之内) 误解:HTTP 协议下的 Get 请求参数长度是有大小限制的,最大不能超过XX,而 Post 是无限制的。 1、首先即使有长度限制,也是限制的是整个 URI 长度,而不仅仅是你的参数值数据长度。 2、HTTP 协议从未规定 GET/POST 的请求长度限制是多少。 **以下内容摘自 《关于 HTTP GET/POST 请求参数长度最大值的一个理解误区》, 文章时间为 2013年的。可能以当前最新的浏览器有出入 ** The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths. 3、所谓的请求长度限制是由浏览器和 web 服务器决定和设置的,各种浏览器和 web 服务器的设定 均不一样,这依赖于各个浏览器厂家的规定或者可以根据 web 服务器的处理能力来设定。 The limit is in MSIE and Safari about 2KB, in Opera about 4KB and in Firefox about 8KB, (255 bytes if we count very old browsers) . We may thus assume that 8KB is the maximum possible length and that 2KB is a more affordable length to rely on at the server side and that 255 bytes is the safest length to assume that the entire URL will come in. If the limit is exceeded in either the browser or the server, most will just truncate the characters outside the limit without any warning. Some servers however may send a HTTP 414 error. If you nee

JVM第一篇:一个Java内存泄漏的排查案例

JVM第一篇:一个Java内存泄漏的排查案例

最近在看《深入理解Java虚拟机:JVM高级特性与最佳实践》(第二版)这本书,理论+实践结合,深入浅出,强烈推荐给大家。 这两天在“小怪的java群”里面也对JVM内容进行了一个讨论,讨论的内容主要包括如下几个方面: 1)内存溢出和内存泄露的介绍? 2)如何排查和处理内存泄露? 一、内存溢出和内存泄露 一种通俗的说法。 1、内存溢出:你申请了10个字节的空间,但是你在这个空间写入11或以上字节的数据,出现溢出。 2、内存泄漏:你用new申请了一块内存,后来很长时间都不再使用了(按理应该释放),但是因为一直被某个或某些实例所持有导致 GC 不能回收,也就是该被释放的对象没有释放。 下面具体介绍。 1.1 内存溢出 java.lang.OutOfMemoryError,是指程序在申请内存时,没有足够的内存空间供其使用,出现OutOfMemoryError。 产生原因 产生该错误的原因主要包括: JVM内存过小。 程序不严密,产生了过多的垃圾。 程序体现 一般情况下,在程序上的体现为: 内存中加载的数据量过于庞大,如一次从数据库取出过多数据。 集合类中有对对象的引用,使用完后未清空,使得JVM不能回收。 代码中存在死循环或循环产生过多重复的对象实体。 使用的第三方软件中的BUG。 启动参数内存值设定的过小。 错误提示 此错误常见的错误提示: tomcat:java.lang.OutOfMemoryError: PermGen space tomcat:java.lang.OutOfMemoryError: Java heap space weblogic:Root cause of ServletException java.lang.OutOfMemoryError resin:java.lang.OutOfMemoryError java:java.lang.OutOfMemoryError 解决方法 增加JVM的内存大小 对于tomcat容器,找到tomcat在电脑中的安装目录,进入这个目录,然后进入bin目录中,在window环境下找到bin目录中的catalina.bat,在linux环境下找到catalina.sh。 编辑catalina.bat文件,找到JAVA_OPTS(具体来说是 set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%")这个选项的位置,这个参数是Java启动的时候,需要的启动参数。 也可以在操作系统的环境变量中对JAVA_OPTS进行设置,因为tomcat在启动的时候,也会读取操作系统中的环境变量的值,进行加载。 如果是修改了操作系统的环境变量,需要重启机器,再重启tomcat,如果修改的是tomcat配置文件,需要将配置文件保存,然后重启tomcat,设置就能生效了。 优化程序,释放垃圾 主要思路就是避免程序体现上出现的情况。避免死循环,防止一次载入太多的数据,提高程序健壮型及时释放。因此,从根本

Java定时任务框架对比

Java定时任务框架对比

汇总情况 Quzrzt LTS Elastic-Job xxl-Job saturn opencorn antares 1. 什么是集群,分布式定时任务 把分散的,可靠性差的计划任务纳入统一的平台,并实现集群管理调度和分布式部署的一种定时任务的管理方式。叫做分布式定时任务。 2. 常见开源方案 elastic-job , xxl-job ,quartz , saturn, opencron , antares, lts 2.1 elastic-job elastic-job 是由当当网基于quartz 二次开发之后的分布式调度解决方案 , 由两个相对独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成 。 Elastic-Job-Lite定位为轻量级无中心化解决方案,使用jar包的形式提供分布式任务的协调服务。 Elastic-Job-Cloud使用Mesos + Docker(TBD)的解决方案,额外提供资源治理、应用分发以及进程隔离等服务 亮点: 基于quartz 定时任务框架为基础的,因此具备quartz的大部分功能 使用zookeeper做协调,调度中心,更加轻量级 支持任务的分片 支持弹性扩容 , 可以水平扩展 , 当任务再次运行时,会检查当前的服务器数量,重新分片,分片结束之后才会继续执行任务 失效转移,容错处理,当一台调度服务器宕机或者跟zookeeper断开连接之后,会立即停止作业,然后再去寻找其他空闲的调度服务器,来运行剩余的任务 提供运维界面,可以管理作业和注册中心。 官方亮点说明: 分布式 重写Quartz基于数据库的分布式功能,改用Zookeeper实现注册中心。 并行调度 采用任务分片方式实现。将一个任务拆分为n个独立的任务项,由分布式的服务器并行执行各自分配到的分片项。 弹性扩容缩容 将任务拆分为n个任务项后,各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群,或现有服务器下线,elastic-job将在保留本次任务执行不变的情况下,下次任务开始前触发任 务重分片。 集中管理 采用基于Zookeeper的注册中心,集中管理和协调分布式作业的状态,分配和监听。外部系统可直接根据Zookeeper的数据管理和- 监控elastic-job。 定制化流程型任务 作业可分为简单和数据流处理两种模式,数据流又分为高吞吐处理模式和顺序性处理模式,其中高吞吐处理模式可以开启足够多的线程快速的处理数据,而顺序性处理模式将每个分片项分配到一个 独立线程,用于保证同一分片的顺序性。 失效转移 弹性扩容缩容在下次作业运行前重分片,但本次作业执行的过程中,下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样 失效转移功能也会

Java 伪共享的原理深度解析以及避免方法

Java 伪共享的原理深度解析以及避免方法

缓存系统中的缓存是以缓存行(cache line)为单位存储的,当多线程修改互相独立的变量时,如果这些变量共享同一个缓存行,因为都会导致同一个缓存行失效而会无意中影响彼此的性能,这就是伪共享(false sharing)。由于从代码中很难看出是否会出现伪共享,有人将其描述成无声的性能杀手。 1 CPU Cache 众所周知,CPU的运算速度远远快于主内存、硬盘的运算速度。为了解决计算机系统中主内存与CPU 之间运行速度差问题,避免直接访问内存或者磁盘,降低因为速度差对CPU整体吞吐量的影响,一般会在CPU与主内存之间添加一级或者多级高速缓冲结构( Cache )。这个Cache 一般是被集成到CPU 内部的,所以也叫CPU Cache。 按照数据读取顺序和与 CPU 结合的紧密程度,CPU 缓存可以分为一级缓存L1,二级缓存L2,部分高端 CPU 还具有三级缓存L3。每一级缓存中所储存的全部数据都是下一级缓存的一部分,越靠近 CPU 的缓存越快也越小。L1和L2只能被一个单独的 CPU 核使用,L3被CPU 核共享,主存由所有 CPU 核共享。 当 CPU 执行运算的时候,它先去 L1 查找所需的数据,再去 L2,然后是 L3,最后如果这些缓存中都没有,所需的数据就要去主内存拿。走得越远,运算耗费的时间就越长。所以如果你在做一些很频繁的事,你要确保数据在 L1 缓存中。 引用《深入理解计算机系统》书中关于CPU缓存和内存、硬盘存储器的层次结构: 现代多核架构,一个物理 CPU 可以存在多个物理 Core,而每个 Core 又可以存在多个硬件线程: 2 Cache Line 计算机缓存系统中是以缓存行(cache line)为单位存储的,Cache Line 是 CPU 和主存之间数据传输的最小单位,缓存行通常是 64 字节。 当一行 Cache Line 被从内存拷贝到 Cache 里,Cache 里会为这个 Cache Line 创建一个条目。这个 Cache 条目里既包含了拷贝的内存数据,即 Cache Line,又包含了这行数据在内存里的位置等元数据信息。 当CPU 访问某个变量时,首先会去看CPU Cache 内是否有该变量,如果有则直接从中获取,否则就去主内存里面获取该变量,然后把该变量所在内存区域的一个Cache 行大小的内存复制到Cache 中。由于存放到Cache 行的是内存块而不是单个变量,所以可能会把多个连续的变量存放到一个Cache 行中。 由此,所以通常情况下访问连续存储的数据会比随机访问要快,访问数组结构通常比链结构快,因为通常数组在内存中是连续分配的。注意:一些JVM实现中大数组不是分配在连续空间的。 3 伪共享 如上图,变量x 和y 同时被放

联系我们

联系电话

4000-640-466

联系邮箱

service@f-li.cn

办公地址

上海黄浦区外滩源1号

谢谢,您的信息已成功发送。
请填写信息。